אבטחה ועמידה בדרישות

ClinicaOS נבנתה מתוך גישה של "אבטחה כברירת מחדל" (security-first). אנו מתייחסים למידע רפואי של מטופלים כנכס הרגיש ביותר במערכת, ומיישמים עיקרון של הגנה לעומק (defense in depth): שכבות בקרה מרובות ועצמאיות, כך שכשל בשכבה אחת אינו חושף את המידע.

מאחר שהמערכת מעבדת מידע בריאותי, מאגרי המידע מנוהלים ברמת האבטחה "הגבוהה" לפי תקנות הגנת הפרטיות (אבטחת מידע), התשע"ז-2017. עקרונות היסוד שלנו כוללים:

• מזעור מידע — איסוף ושמירה רק של מה שנדרש למתן השירות.
• בידוד לקוחות (multi-tenancy) — כל פריט מידע משויך למרפאה בעלת המידע, וגישה נחסמת מעבר לגבולות המרפאה.
• הרשאות לפי תפקיד (RBAC) — גישה למידע ולפעולות נקבעת לפי תפקיד המשתמש ולפי הצורך לדעת.
• הצפנה במנוחה ובמעבר — שדות רגישים מוצפנים, וכל התקשורת מוגנת ב-TLS.
• תיעוד ביקורת בלתי ניתן לשינוי — פעולות רגישות נרשמות ביומן שלא ניתן לערוך או למחוק.
• ניטור ותגובה — איתור חריגות ושגיאות תוך נטרול מידע רפואי מזהה.

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

הצפנת שדות במנוחה

שדות מידע רגישים במיוחד — לרבות מספרי תעודת זהות (תעודת זהות) ופרטים מזהים נוספים — מוצפנים ברמת השדה לפני שמירתם בבסיס הנתונים. ההצפנה מבוצעת באמצעות אלגוריתם AES-256-GCM הממומש על גבי ספריית ההצפנה המובנית של סביבת ההרצה (Node.js crypto), המספקת הן סודיות והן שלמות (authenticated encryption) של המידע.

• AES-256-GCM — הצפנה סימטרית באורך מפתח 256 ביט עם אימות שלמות מובנה.
• מפתחות ההצפנה מנוהלים בנפרד מהמידע ומוגדרים כמשתני סביבה מאובטחים, לא בקוד המקור.
• שדות הניתנים לחיפוש משתמשים בהצפנה דטרמיניסטית מבוקרת, בעוד שאר השדות מוצפנים עם וקטור אתחול (IV) אקראי לכל ערך.
• קריאה של שדות מזהים מתועדת ביומן גישה למידע רפואי (PHI).

הצפנה במעבר

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

בידוד נתונים בין מרפאות

המערכת היא רב-דיירת (multi-tenant): מרפאות שונות חולקות תשתית אך מידע כל מרפאה מבודד באופן לוגי. כל רשומה הנושאת מידע של מרפאה משויכת למזהה המרפאה (clinic_id), והמזהה נגזר תמיד מתוך הפעלת המשתמש המאומתת ולעולם אינו מתקבל מצד הלקוח. כל קריאה וכתיבה למידע מסוננת לפי מזהה המרפאה, כך שמשתמש של מרפאה אחת אינו יכול לגשת למידע של מרפאה אחרת.

הרשאות מבוססות תפקיד (RBAC)

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

אימות וסיסמאות

סיסמאות המשתמשים אינן נשמרות כטקסט גלוי לעולם. הן עוברות גיבוב (hashing) באמצעות אלגוריתם bcrypt עם פרמטר עלות (cost factor) של 13, המעניק עמידות גבוהה בפני התקפות כוח גס. ההפעלות (sessions) מנוהלות באמצעות אסימוני JWT עם תוקף מתחדש, ומצב המשתמש (תפקיד, שיוך למרפאה, פעיל/מושבת) מאומת מחדש מול בסיס הנתונים מעת לעת.

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

פעולות רגישות במערכת — לרבות גישה למידע רפואי, שינויי הרשאות והתחברויות — נרשמות ביומן ביקורת (audit log). יומן הביקורת תוכנן להיות בלתי ניתן לשינוי (immutable): לאחר רישום, לא ניתן לערוך או למחוק רשומות ביומן.

• אכיפה ברמת בסיס הנתונים באמצעות טריגר (trigger) החוסם כל ניסיון עדכון או מחיקה ומחזיר שגיאה, ללא תלות בהרשאות התפקיד.
• מדיניות אבטחה ברמת השורה (Row Level Security) המגבילה גישה לרשומות הביומן.
• קוד היישום מורשה אך ורק להוסיף רשומות (INSERT) ליומן — לא לעדכן ולא למחוק.
• כל רשומה כוללת חותמת זמן באזור זמן, מזהה השחקן, סוג הפעולה ומזהה המרפאה.

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

• אחסון קבצים — קבצים ומסמכים (לרבות הדמיה רפואית) מאוחסנים באחסון אובייקטים של Cloudflare R2, עם גישה מבוקרת באמצעות כתובות חתומות לזמן מוגבל.
• בסיס נתונים — מאוחסן ב-Neon (Postgres מנוהל) באזור גאוגרפי באיחוד האירופי (EU), עם הצפנה במנוחה ובמעבר ברמת הספק.
• מדיניות אבטחת תוכן (CSP) — נאכפת לכל בקשה עם ערך nonce ייחודי, להגנה מפני הזרקת סקריפטים (XSS), ללא התרת סקריפטים מוטמעים שאינם חתומים.
• הגבלת קצב — נאכפת באמצעות שירות Upstash על נקודות קצה רגישות, לרבות נתיבי האימות, להגנה מפני התקפות אוטומטיות.
• אימות חתימות webhook — בקשות נכנסות מספקים חיצוניים (כגון סליקה והודעות) מאומתות באמצעות חתימה קריפטוגרפית, עם חלון הגנה מפני שידור חוזר (replay) ומניעת עיבוד כפול של אותה עסקה. בקשות לא חתומות נדחות.
• ניטור שגיאות — באמצעות Sentry, כאשר שיתוף מידע מזהה כברירת מחדל מושבת (sendDefaultPii: false) ומופעל מנגנון לסינון מידע רפואי (PHI) לפני שליחת הדיווח.

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

אנו מחויבים לעמידה במיטב נהלי אבטחת המידע. נכון למועד פרסום מסמך זה, אנו פועלים לקראת הסמכת ISO 27001 לניהול אבטחת מידע, ובונים את מערכת ניהול אבטחת המידע (ISMS) שלנו בהתאם לעקרונות התקן.

ללא תלות בתהליך ההסמכה, אנו מיישמים את בקרות האבטחה הטכניות והארגוניות המתוארות במסמך זה, ופועלים בהתאם לדרישות תקנות הגנת הפרטיות (אבטחת מידע), התשע"ז-2017 ברמת האבטחה הגבוהה החלה על מידע רפואי.

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

ניתן לפנות אלינו בכתובת הייעודית: security@clinicaos.co.il. אנא כללו בדיווח תיאור של החולשה, שלבים לשחזורה והשפעתה האפשרית. אנו מתחייבים לאשר קבלת הדיווח, לבחון אותו ולעדכן את הפונה בהתאם להתקדמות הטיפול.

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