---
title: "מרכז האמון של Hanah (בריטניה והאיחוד האירופי)"
description: "מרכז האמון של Hanah (בריטניה והאיחוד האירופי): רשומות המטופלים של קליניקות בבריטניה נשמרות בבריטניה. בקרות אבטחה ופרטיות, וספקי השירות של הפריסה בבריטניה, שמשרתת גם קליניקות באיחוד האירופי."
source: https://hanah.health/he/uk/trust/
---

# מרכז האמון

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

✅ הושלם 🔧 מיושם בפתרון ייעודי

סקירה כללית בקרות ספקי שירות משאבים

**למי זה מיועד:** קליניקות, רשתות בריאות, ממונים על הגנת הפרטיות וצוותי אבטחת מידע שעורכים בדיקת נאותות ל-Hanah. **במבט מהיר:** מרכז האמון הזה מסכם את בקרות האבטחה של Hanah ואת ספקי השירות שנכללים בפריסת הייצור באזור . הרשומות הקליניות נשמרות באזור . זיהוי הדיבור והניסוח ב-AI פועלים אצל ספקים מתמחים מחוץ לאזור, בעיקר בארה״ב, בתנאים שאוסרים אימון על התוכן שלכם. ראיות מפורטות יותר נמצאות במדריך האבטחה והתפעול שלנו (Security & Operations Handbook); לשונית **הבקרות** מתארת איך כל בקרה מיושמת.

### בקרות אבטחה

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

לבקרות ←

### ספקי שירות

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

לספקי השירות ←

### משאבים והצעדים הבאים

סטטוס השירות, ואיך לבקש את חבילות המדיניות המלאות בכפוף להסכם סודיות (NDA).

למשאבים ←[

### מתודולוגיית אימות

איך אנחנו מודדים את דיוק התמלול ואת ההזיות בתיעוד: מערך בדיקה אחד, קורפוס אחד, שתי שכבות הערכה (WER + פאנל שופטים של מודלי שפה). אלה הכללים שלפיהם מוערך כל מספר שאנחנו מפרסמים.

לקריאת המתודולוגיה ←](https://hanah.health/he/uk/trust/wer-methodology/)[

### שקיפות האימות

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

לדוח ←](https://hanah.health/he/uk/trust/transparency/)

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

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

## תשתית ופלטפורמה

אבטחת תשתית

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

-   ✅
    
    טכנית מדיניות
    
    **עומסי ייצור שמתארחים באזור**
    
    שרתי האפליקציה הראשיים, מסדי הנתונים, אחסון האובייקטים והגיבויים של הפריסה באזור נמצאים באותו אזור. רשומות מנהליות מתעדות את האזורים ואת אישור השינויים, והפריסה הטכנית מקבעת את המשאבים לפרויקט האזורי.
    
-   ✅
    
    טכנית
    
    **הצפנה בתעבורה**
    
    תעבורה נכנסת מהאינטרנט משתמשת ב-TLS מודרני. התעבורה לספקי זיהוי הדיבור ולספקי מודלי ה-AI משתמשת ב-TLS אל נקודות הקצה שהוגדרו לכל ספק. זו בקרה טכנית שמאומתת בסקירות ארכיטקטורה ובתצורת הפריסה.
    
-   ✅
    
    טכנית מדיניות
    
    **הצפנה באחסון**
    
    מסדי נתונים, אחסון אובייקטים ואובייקטי גיבוי משתמשים באלגוריתמים מקובלים בתעשייה (למשל AES-256-GCM), עם מפתחות שמנוהלים לפי מדיניות הקריפטוגרפיה שלנו. גיבויי WAL-G מוסיפים הצפנה בצד הלקוח לפני האחסון מחוץ לאתר.
    
-   ✅
    
    טכנית ספקים
    
    **הגנת DDoS ו-WAF בקצה הרשת**
    
    שכבת קצה מנוהלת עומדת לפני שמות המארחים הציבוריים, סופגת מתקפות נפח ומפעילה חוקי WAF נגד שימוש לרעה נפוץ ברשת. ההגנות ברמת הספק ומדיניות חומת אש הדוקה נשארות בתוקף מאחורי שכבת הקצה.
    
-   ✅
    
    טכנית מדיניות
    
    **זיהוי חדירות**
    
    זיהוי בכמה שכבות: פלטפורמת האירוח מספקת IDS ברמת הרשת, וכל מכונה וירטואלית (VM) מריצה fail2ban (מניעת מתקפות brute-force על SSH), UFW עם מדיניות ברירת מחדל של חסימה, ועדכוני אבטחה אוטומטיים. אירועי אימות וגישה מה-auth-proxy נשלחים למערך Loki/Grafana מרכזי, כך שדפוסי התחברות חריגים מופיעים בלוחות הבקרה ובהתראות. המדיניות מגדירה מי אחראי לטיפול ראשוני כשהתראה מופעלת. IDS בזמן ריצה ברמת הקרנל לקונטיינרים הוא שיפור מתוכנן מעל הבסיס הזה.
    

## מוצר ואפליקציה

אבטחת המוצר

איך משתמשים מזדהים, איך ההרשאות נאכפות במוצר ובשכבת ה-API, ואיך אנחנו בונים ומשחררים תוכנה. שילוב של אכיפה טכנית (JWT, RBAC) עם דרישות מנהליות למחזור פיתוח מאובטח (SDLC) ולסקירה.

-   ✅
    
    טכנית ספקים
    
    **אימות וסשנים**
    
    מטפלים מזדהים דרך ספק זהויות מנוהל (תהליכים בסגנון OIDC/OAuth), וכל נתיב API מאמת את הזהות. משך הסשן והתנהגות הנעילה תואמים את מדיניות בקרת הגישה שלנו.
    
-   ✅
    
    טכנית מדיניות
    
    **בקרת גישה מבוססת תפקידים**
    
    היכולות של מטפלים, של מטופלים ושל מנהלי מערכת מופרדות במודל הנתונים ובשכבת ה-GraphQL, כך שהרשאה מינימלית היא ברירת המחדל. הגדרות התפקידים ותדירות הסקירה שלהן מתועדות ברמה המנהלית.
    
-   ✅
    
    טכנית מדיניות
    
    **חובת MFA בנתיבים בעלי הרשאות מוגברות**
    
    חובת MFA נאכפת, דרך ספק הזהויות שלנו, בחשבונות שיכולים לשנות הגדרות רגישות לאבטחה או לגשת לנתונים בסיכון גבוה.
    
-   ✅
    
    טכנית מדיניות
    
    **מחזור פיתוח מאובטח**
    
    שינויים עוברים דרך ניהול קוד מקור, סקירה ותלויות מקובעות. השפעת האבטחה נשקלת בפיצ׳רים מהותיים כשער מנהלי, וכלים טכניים (Dependabot ועוד) תומכים בהיגיינה שוטפת.
    
-   ✅
    
    טכנית מדיניות
    
    **רשימת רכיבי תוכנה (SBOM)**
    
    כל גרסה כוללת רשימת מלאי של התלויות בפורמט קריא למכונה, לצורך תגובה לפגיעויות. ייצוא ה-SBOM משולב ב-CI כחלק מתוכנית הבטחת שרשרת האספקה שלנו.
    

## נתונים ופרטיות

נתונים ופרטיות

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

-   ✅
    
    טכנית מדיניות
    
    **שמירה ומחיקה של תוצרי ההקלטה ברקע**
    
    חומרי אודיו ותמליל נשמרים כברירת מחדל לתקופה קצרה ונמחקים אוטומטית. רשומות קליניות נשמרות לפי מדיניות השמירה של כל ארגון. אחרי שילוב עם מערכת הרשומות שלכם, הרשומה הקלינית המחייבת נשארת שלכם.
    
-   ✅
    
    טכנית מדיניות
    
    **יומן מחיקות חסין שינויים ודוחות רבעוניים**
    
    מחיקות שנובעות ממדיניות השמירה נרשמות ב-`deletion_log`, טבלת Postgres שמאפשרת הוספה בלבד, בלי הרשאות `UPDATE` או `DELETE` לאף תפקיד. כל שורה מקושרת לשורה שלפניה באמצעות שרשרת גיבוב SHA-256 (`row_hash = sha256(prev_hash ‖ canonical(metadata))`), כך ששינוי או הסרה של שורה מוקדמת כלשהי שוברים את כל הגיבובים שאחריה, והמאמת שבתוך מסד הנתונים, `hanah_verify_deletion_chain()`, מזהה זאת. גם טבלאות הביקורת הנלוות (`ai_audit`, `secret_access_audit`) מאפשרות הוספה בלבד. סיכומים רבעוניים ללקוחות מופקים באמצעות `hanah_deletion_report_quarter(year, quarter)`.
    
-   ✅
    
    מדיניות טכנית
    
    **זכות הגישה והתיקון של נושא המידע**
    
    אנשים יכולים לבקש גישה למידע האישי שלהם או את תיקונו. Hanah מתעדת לוחות זמנים, פורמטים (ייצוא JSON וייצוא קריא לבני אדם) ונתיבי הסלמה. הכלים תומכים בייצוא במקומות שבהם הנתונים נמצאים במערכות של Hanah.
    
-   🔧
    
    טכנית מדיניות
    
    **שקיפות ביקורת מאוחדת**
    
    אירועים רלוונטיים לאבטחה (אימות, שימוש בהרשאות, שינויי תצורה) זמינים לשאילתה עבור לקוחות מוסדיים, ואפשר להעביר אותם ל-SIEM שלכם (למשל Microsoft Sentinel) כשהדבר סוכם בחוזה. מוגדר לכל לקוח בנפרד.
    

## AI ובטיחות קלינית

אבטחה ותאימות של AI

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

-   ✅
    
    ספקים מדיניות טכנית
    
    **ללא שימוש משני לאימון מודלים**
    
    תנאי השימוש של ספקי זיהוי הדיבור ומודלי ה-AI שלנו אוסרים אימון על תוכן של לקוחות, והבקשות נשלחות כשהאחסון בצד הספק כבוי, בכל מקום שהספק מאפשר זאת. ל-Hanah אין תהליך אימון פנימי על המידע הרפואי שלכם. סקירות ספקים מנהליות תומכות בטענה הזו.
    
-   ✅
    
    מדיניות טכנית
    
    **בקרה אנושית לפני הסתמכות קלינית**
    
    רשומות שנוצרו מחייבות בדיקה ואישור סופי מפורשים של המטפל לפני שהן נחשבות לחלק מהרשומה הקלינית. זו גם בקרה במוצר (שערים בתהליך העבודה) וגם התחייבות מדיניות בתסקיר ההשפעה על הפרטיות (PIA).
    
-   ✅
    
    מדיניות טכנית
    
    **מתודולוגיית WER ותוצאות קבוצות הבדיקה שפורסמו**
    
    מערך בדיקה אחד ושתי שכבות הערכה, שרצים בכל סבב הערכה: **שיעור שגיאות המילים** מול תמלילי ייחוס מילה במילה (שכבה A), **ופאנל שופטים של מודלי שפה** שמודד גם _כיסוי_ (האם הרשומה מכילה כל ציפייה שנרשמה מראש?) וגם _הזיות_ (האם הרשומה מכילה טענות שהתמליל לא תומך בהן, כלומר תוכן שהמודל המציא?). [המתודולוגיה המלאה](https://hanah.health/he/uk/trust/wer-methodology/) מפורסמת, [והתוצאות העדכניות](https://hanah.health/he/uk/trust/transparency/) מוצגות ישירות מהפלט המצרפי של מערך הבדיקה. הקורפוס ממשיך להתקדם בשלבים: v1 (סינתטי) ← v2 (משחקי תפקידים) ← v3 (אמיתי, מבוסס הסכמה) ← v4 (משותף עם שותפים ממערכות בריאות).
    
-   ✅
    
    טכנית מדיניות
    
    **הזרקת פרומפט וניטור פלט לא בטוח**
    
    פרומפטי המערכת נשלטים בצד השרת, והקלט מוגבל על ידי תהליך העבודה הקליני (אין ממשק צ׳אט חופשי). מסווגי הבטיחות של הספק רצים על כל יצירה. כשהם מופעלים, הזרם מחזיר סיבת סיום של מסנן תוכן, שנרשמת בשורת `ai_audit` של אותה קריאה, יחד עם קוד שגיאה קנוני `ai.content_policy`, זמן תגובה, טוקנים ומזהה Tempo trace. דפוסים חריגים מופיעים בלוחות בקרה שנבנים על טבלת הביקורת הזו. זיהוי חריגות התנהגותיות בין קריאות, לאיתור דפוסי שימוש לרעה, הוא שיפור מתוכנן מעל הבסיס הזה.
    
-   ✅
    
    טכנית מדיניות
    
    **תיעוד הסכמה של כל המשתתפים בתוך המוצר**
    
    כשהמטפל לוחץ על הקלטה, המוצר פותח חלון הסכמה שמחייב אישור מפורש שהתקבלה הסכמה מהמטופל ומכל משתתף אחר במפגש. ההקלטה לא יכולה להתחיל לפני שהאישור הזה ניתן, והאישור נקשר למפגש יחד עם מדיניות הקליניקה שמוזכרת בתסקיר ההשפעה על הפרטיות.
    

## הארגון וצדדים שלישיים

אבטחה ארגונית

איך Hanah, החברה, מנהלת את האבטחה: אחריותיות, מדיניות, אימות בלתי תלוי ושילוב עם כלי האבטחה של הלקוחות. אלה בעיקר בקרות מנהליות, ולחלקן יש תוצרים טכניים (למשל מחברי SIEM).

-   ✅
    
    מדיניות
    
    **ממשל אבטחה ומרשם סיכונים**
    
    בכיר מוגדר בשמו אחראי לאבטחת המידע. סיכונים נרשמים עם בעלים ותאריכי יעד ונבדקים במועדים קבועים. זה תואם את מה שרוכשים מצפים לו בדרך כלל ממערכת ניהול בסגנון ISO, גם בהיקף הנוכחי שלנו.
    
-   ✅
    
    מדיניות
    
    **חבילת מדיניות שאושרה בדירקטוריון**
    
    מדיניות פורמלית מכסה גישה, קריפטוגרפיה, תגובה לאירועים, ספקים וניהול שינויים. החבילה אושרה בדירקטוריון ומנוהלת בבקרת גרסאות. התוכן המלא זמין בכפוף להסכם סודיות (NDA).
    
-   🔧
    
    מדיניות טכנית
    
    **העברה ל-SIEM של הלקוח (למשל Sentinel)**
    
    אירועי אבטחה ממערכות שבשליטת Hanah מועברים לסביבת ה-Sentinel שלכם (או למערכת מקבילה) לניטור משותף, כשהדבר סוכם בחוזה. מוגדר לכל לקוח מוסדי בנפרד.
    

אלה סוגי ספקי השירות שעשויים **לעבד או לאחסן נתוני לקוחות של Hanah** בארכיטקטורת הייצור שלנו באזור , מה כל אחד מהם מטפל בו, מה הוא שומר והיכן הוא מעבד נתונים. כל ספק מחויב בחוזה להגן על נתוני הלקוחות, ואף אחד מהם לא רשאי לאמן עליהם מודלים. כניסת המטפלים משתמשת בתשתית זהויות גלובלית שאינה מחזיקה **שום מידע רפואי של מטופלים**. אותם סוגים מופיעים בנספח C של [הסכם עיבוד הנתונים](https://hanah.health/dpa/#annex-c) שלנו.

| סוג השירות | מטרה | הנתונים שמטופלים | שמירה | אזור העיבוד |
| --- | --- | --- | --- | --- |

שקיפות תפעולית: דף **סטטוס** ציבורי (זמינות ואירועים) עומד לצד נקודת הקצה `/healthz` של סביבת הייצור, שמשמשת את הניטור שלנו.

[סטטוס השירות](https://hanah.health/he/uk/trust/status/ "תקינות לכל רכיב, זמינות ב-90 הימים האחרונים והיסטוריית תקלות של הפריסה בבריטניה.") [לבקשת חבילת האבטחה המלאה בכפוף להסכם סודיות (NDA)](mailto:security@hanah.health?subject=Trust%20%2F%20security%20pack%20request) [חזרה ל-hanah.health](https://hanah.health/he/)

PhysiPal Pty Ltd (פועלת בשם Hanah) – . מרכז האמון הזה הוא סיכום כללי. התחייבויות חוזיות ותנאי עיבוד הנתונים שבתוקף בעת החתימה גוברים על הדף הזה. סימוני האימוג׳י של הסטטוס (✅ 🔧) זמניים ויוסרו אחרי אימות בלתי תלוי של כל שורה.