TechTok

Cyber security tech session with Nir Zuk @ Palo Alto visitor’s center

IOT On The Nutshel

IOT On THe Nutshell.mp4

Microservices - To be, or not to be

כאשר אנו שוקלים לממש יישום או המעבר לארכיטקטורה מבוססת Microservices עלינו לבחון מספר היבטים:
1) הצורך – מדוע אנו מעוניינים לבצע את היישום בארכיטקטורה זו?
האם מדובר בפתרון המורכב ממספר רכיבים אשר המימוש שלהם בארכיטקטורה זו יביא ל:
• גמישות בתהליכי השדרוג
• Scalability
• Reuse
או בשל העובדה שמדובר ב- Trend טכנולוגי אשר נראה כי "כולם מממשים".
כמובן שאם התשובה היא המשפט האחרון בסעיף, אין הצדקה לבצע את המהלך.
2) עלות תועלת – מה נקבל בסוף התהליך?
במידה ואנו מעוניינים להשיק מוצר בפרק זמן קצר וקצוב מבחינת לוחות הזמנים ייתכן ונדרש לממש את הפתרון בארכיטקטורת Monolithic כיוון שהדבר יאפשר לנו לעמוד בהם.
גם כאשר נחליט לממש בשלב ראשון את הפתרון בארכיטקטורת Monolithic אנו יכולים להניח את היסודות בחלק משכבות יישום הפתרון כך שנוכל לעשות Decupling בצורה יותר קלה ויעילה בהמשך במידה ונחליט לעבור לארכיטקטורת Microservices.
3) מימוש – כיצד אנו מעוניינים לממש את המהלך?
4) יעילות המהלך- מה נקבל כתוצאה מיישום הארכיטקטורה?
האם בסיום התהליך נקבל X רכיבים אשר התלות בינם מינימאלית או שנמצא כי מימשנו את הארכיטקטורה עם כמות גדולה של Services אשר מתקשרים בינם באופן תמידי ובכך מביאים לחוסר יעילות של הפתרון.
עלינו לוודא כי אנו כותבים KPIs מדידים לבחינת היישום לפני, תוך כדי ובסיומו.
כאשר אנו ניצבים בפני החלטה הרת גורל באם לממש פתרון של מעבר ל- Microservices Architecture עלינו לבחון האם מדובר במהלך אשר יניב מבחינה עסקית (לא רק טכנולוגית) ערך עבור המשתמשים/לקוחות או האם אנו מעוניינים ביישומו רק בשם החדשנות הטכנולוגית (לעיתים גם זו תשובה מספקת).
הייתרון במימוש של ארכיטקטורה זו ברור בעידן אשר בו אנו נדרשים ליעילות מרבית בהיבטי עמידה בעומסים, תגובתיות, שדרוגים וניהול גרסאות אולם יש לא מעט יישומים של מערכות ניהול ארגוניות מסורתיות אשר יעילותם בארכיטקטורת Monolithic גבוהה יותר מאשר ב- Microservices.

Sharon Haris

מצורף בלוג ראשון מבין שניים בסדרה אשר מציג בקצרה את
מהות ארכיטקטורת ה- Microservices.....

ארכיטקטורת ה- Microservices (MSA) הוצגה לראשונה בשנת 2005 על ידי פיטר רודג'רס כאשר ב- Session אשר הוא העביר הוא השתמש בביטוי Micro-Web Services כדי לתאר את הפרדת השירותים במערכת כ- Loose Coupling כלומר ללא תלות אחד בשני.
השירותים מתקשרים זה עם זה באמצעות API Gateway אשר משמש כמתווך ומבצע פעולות כגון העברת ה- Tokens לרכיבי ה- IAM לצורך הזדהות, המרות לפורמטים שונים וכ- Catalog לכלל השירותים אשר נצרכים במערך.
הגישה למקור המידע (DB) בתצורת מערך זו שונה בתכלית לעומת ארכיטקטורת ה- Monolithic המוכרת. הסיבה נעוצה בעובדה שבארכיטקטורת MS לכל שירות מסד נתונים משלו ובו הוא מנהל את המידע הרלוונטי לו. ניתן לסנכרן את המידע בין מסדי הנתונים של השירותים השונים על מנת שהמערכת אותה אנו מפתחים בארכיטקטורה זו תכיל מידע אחוד לאורך כל שכבות הפתרון. מימוש תצורת הכתיבה למסדי הנתונים עשויה להשתנות מ- ACID ל- BASE בחלק מרכיבי הפתרון וזאת בשל התצורה הארכיטקטונית (הפרדת השירותים) שלו. הכתיבה כ- BASE מאפשרת מימוש מהיר ובעל נפח רב יותר של כתיבת וקריאת מידע למסדי הנתונים בעוד שמתפשרים על ה- Availability וה- Consistency, מתאים ליישומים בעלי נפח תעבורה גדול הדורשים זמני תגובה מהירים.
במידה ונבחר לממש את הפתרון ב- MSA נידרש לשים לב שאנו שומרים על האיזון בין פירוק מרכיבי הפתרון ליחידות קטנות אך לא קטנות מידי כיוון שפירוק מסוג זה יגרום לאיבוד היעילות של הפתרון כיוון ששני שירותים אשר מעבירים בינם לבין עצמם מידע בצורה מאסיבית אולי צריכים להיות שירות אחד ולפעול בצורה יעילה יותר. התכנון צריך להיעשות אחרי ניתוח הצרכים אשר הובאו בפנינו מהיחידות העסקיות, ולאחר קבלת המידע נוכל לבחון את מידת ורמת פירוק השירותים ליחידות השונות.

דוגמא למימוש של MSA באתר/אפליקציית מסחר B2C
המערכת מספקת שירותי קניית מוצרים באתר ובאפליקציית Mobile כאשר היא מורכבת משישה תהליכים מרכזיים:
1) Authentication
2) Checkout
3) Order
4) Payment
5) Inventory
6) Shipment
כל אחד מהתהליכים הללו מורכב משכבה של שירותי MS כאשר יש לוודא כי אנו ממשים כל שירות מסוג זה בהלימה ל- Workflow (באמצעות Workflow Engine) של ביצוע תהליך ההזמנה כאשר כל התהליך מקושר לשירות ה- Order של הלקוח אשר מקבל את כל הנתונים באשר לסטאטוס אישור קיום הפריט (Inventory), התשלום (Payment) וכמובן תהליך המשלוח והמעקב (Shipment ו- Tracking).
השרטוט מתאר את הקשר בין הרכיבים ואת ה- Workflow של התהליך החל מההזדהות ועד למשלוח המוצר.
ניתן להרחיב את מפת השירותים למעקב (דרושים ממשקים לחברות השילוח), לאישור המסירה ללקוח ולקבלת משוב לצורך דירוג המוצר או המוכר.

Sharon Haris

Israel Information Technology Conference 2020

ועידת ישראל לטכנולוגיות המידע 2020 הלשכה לטכנולוגיות המידע בישראל Signing and Biologon - Sharon Haris אי - כנס ---------------------------------------------------------------------------------...

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

המגזר השני אליו אתייחס הוא המטופלים אך לפני שארחיב אודות השאת הערך במתן השירותים עבור מגזר זה אקדים ואסביר כי כדי לתת מענה של Ecosystem מלא עבור מגזר זה, יש לייצר מערך שלם של כלים דיגיטאליים עבור הצוותים הקליניים.
כלים אלה יאפשרו לתת מענה ושירות באותה רמת איכות טכנולוגית למטופל. כל עוד הסימטריה במימוש הכלים הדיגיטאליים והטכנולוגיים בין המטופל לצוותים המטפלים תישמר איכות וזמינות הטיפול ישתפרו.
כאשר אנו מספקים למטופל תוצאות בדיקה ואבחוני Online (Tele Medicine) אנו צריכים לצייד את הרופאים והאחיות באפליקציות ונתונים רלוונטיים אשר יהיו זמינים להם מכל מקום ובכל שעה, אפליקציות אלה אינן המערכות הקליניות המסורתיות אשר מצויות בבתי או בקופות החולים.
זו דוגמא למימוש של כלים דיגיטאליים בצורה סימטרית, כל מימוש אשר יעשה בצורה אחרת יביא את המטופל או את איש הצוות הקליני לקבלת או מתן שירות פחות טוב.
המימושים הרלוונטיים אשר אנו יכולים לספק בעולמות הדיגיטל עבור המטופלים:
1) הנגשת מידע "מזוקק" לצוותים הקליניים על ידי שימוש במערכות המבוססות Data Analysis ו- AI.
2) מערכות Tele Medicine משולבות IOT מתקדמות אשר יאפשרו ביצוע מגוון רחב של בדיקות (לרבות בדיקות פולשניות באמצעים לא פולשניים) ללא צורך בביקור במרפאה, בקופה, או בבית החולים.
3) עדכון בזמן אמת של הקרובים או ה- Care Givers של המטופל בעת ביקור בבית החולים אודות מצבו והתקדמות הטיפול בו.
4) ביצוע פענוח מהיר של בדיקות דימות ומעבדה על ידי שימוש במערכות מבוססות AI אשר יאפשרו מאות אלפי פענוחים ללא צורך בהתערבות אנושית למעט פיקוח.
5) ביצוע פעולות פולשניות (ניתוחים) מכל מקום בעולם, מתאפשר על ידי שימוש ברובוטים המופעלים מרחוק (דה וינצ'י) ובתקשורת מהירה (5G).
6) קבלת מידע מוקדם אודות אירועים אשר אמורים להתרחש (Prevention) על ידי שימוש בכלי Predictive Analytics.
7) הקמת מערכי Medical Data Sharing לצרכי מחקר תוך שימת דגש על Data Security and Privacy.
8) שיתוף גלובאלי של רשומת המטופל בין כל הגורמים הרלוונטיים (קליניים, משלמים ומבטחים) בצורה קלה, מהירה ומאובטחת (Blockchain).
בשלושת הבלוגים סקרתי את תצורת יישום ומימוש פתרונות הדיגיטל בעולמות הבריאות.
ניכר כי כדי ליצור מערך הוליסטי של פתרונות יש למפות את אוכלוסיות היעד, להתאים לכל אחת מהן את הכלים והטכנולוגיות הרלוונטיים וליצור אינטגרציה כאשר יש יחסי גומלין בינן (צוות רפואי ומטופל).

Sharon Haris

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

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

• הקמת פורטל רספונסיבי המשלב אזור אישי, קבוצות דיון, צ'אטים, חדשות ב- Live Feed, העלאת תכנים מקצועיים וסוציאליים וכל תוכן רלוונטי אשר יהווה כמוקד ידע ארגוני.
• אפליקציית דיווח שעות וקבלת מידע.
• לוחות דיגיטאליים.
• יצירת אפליקציות לעידוד בריאות המטופל מונחות Gamification.
האפיק השני יהיה בתהליכי גיוס העובדים יישום מערך דיגיטאלי אשר יכלול את הכלים הבאים:
• בניית מערך להגשת קורות החיים והמסמכים הנלווים של המועמדים.
• יצירת אפיקי היזון חוזר עבור המועמדים.
• יצירת ערוצי תקשורת ישירים עם המועמדים, זימון ראיונות, מבחני Online וכיוצא באלה.
• הגשת חוזה דיגיטאלי לחתימה.
• יצירת תהליכי On Boarding אשר מתחילים בתהליכים מקוונים ומסתיימים בחברה.
בבלוג הבא אסקור את הנגשת השירותים ויצירת הערך עבור המטופלים.

Sharon Haris

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

כאשר אנו מתייחסים להטמעת תהליכי דיגיטל בארגונים המכנה המשותף הינו שינוי תפיסתי (לא טכנולוגי) של הנהלת הארגון והגדרת תהליכים התומכים בשינוי זה הלכה למעשה אל מול מקבלי השירות כלומר הלקוחות.
השינויים יכולים לבוא לידי ביטוי ביישום תהליכים פשוטים של הסטת הפעילות הפרונטלית לפעילות טלפונית או ביישום תהליכים הנתמכים בטכנולוגיות מורכבות כגון מתן הצעת שירותים פרסונליים תוך ניתוח התנהגויות הלקוח לאורך זמן וכל זאת ללא התערבות אנושית (ML to human interaction).
מה בכל זאת מבדיל את תפיסת התאמת השירותים הדיגיטליים בין המגזרים?
התשובה היא השירות וקהל היעד אשר מקבל אותו.
לאחר שהצגתי את מהות תפיסת הצעת הערך בשירותים דיגיטאליים ומה מבדיל בינם אתמקד בהצעת שירותים דיגיטאליים בתחום הבריאות.
בתחום הבריאות קיימים שלושה מגזרים עיקריים: קופות החולים, בתי החולים, מכונים ומרפאות (ציבוריים ופרטיים).
לכל אחד מהמגזרים הללו גישה שונה באשר לבניית האסטרטגיה הדיגיטאלית וזאת על פי ההגדרה כי קיימת שונות במתן השירות ובקהל המקבל אותו למרות שלכאורה כולם צרכנים של שירותי בריאות.
הדבר בא לידי ביטוי בתפיסת הערך אשר כל קבוצת לקוחות רואה בקבלת השירותים מהמגזר הרלוונטי, תפיסת הערך של אימא אשר צריכה לקבל מרשם עבור בנה שונה מזו של תייר אשר מגיע לבצע ניתוח מעקפים או ממשפחה של חולה קורונה.
בבלוג הבא אסקור את ההבדלים בהצעת השירותים בין המגזרים השונים בעולם הבריאות.



Sharon Haris

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

ניקח את תחום הדימות הרפואי ונשליך עליו את המודל האינטראופרבילי, נמצא כי קיים סטנדרט IHE לשיתוף בדיקות דימות חוצה ארגונים הנקרא XDSi (cross-enterprise document sharing for imaging) המכיל בתוכו מודול רגיסטרציה של הרשומות המשותפות בין הארגונים השונים והיכולת לאחזר מידע ע"י החוקים שהוגדרו במודול הרגיסטרציה לטובת צפייה בבדיקות דימות מארגוני בריאות ובתי חולים.
ארבעה יתרונות רבים ומשמעותיים של אינטראופרביליות בעולם הדימות:
1) משתמשי הקצה (רדיולוג, רנטגנאי או קלינאי) נשאר לעבוד בסביבה הטבעית שלו, קרי עם מערכת תיק חולה בשילוב RIS ו PACS Viewer הארגוני (עליהם הרחבנו במאמר הקודם), ללא שימוש במוצרי צד שלישי כדי לצפות בבדיקות הדימות ובכך לייעל את תהליכי העבודה המתנהלים בתיק הקליני של המטופל וביכולת עיבוד התמונה הפנים ארגונית בשילוב מערכות AI מתחום הדימות.
2) ייתור של צריבת הדיסקים פר בדיקה למטופל.
3) צפייה במידע דרך פורטלי מטופלים ורופאים כאשר המערכות מותקנות כשירות ענן.
4) צמצום חשיפה מיותרת של קרינת רנטגן למטופלים.
בתחום האינטגרציה הרפואית קיים סטנדרט שתופס תאוצה בשנים האחרונות בשם FHIR – Fast Healthcare Interoperability Resources שהוא אבולוציה של HL7 הסטנדרטי להעברת מידע בין מערכות מידע ומכשירים רפואיים- סטנדרט FHIR משלב מודלים ומתודות קידוד נתונים מודרניים מבוססי Web הכוללות XML, JSON, ,HTTP Atom ו- OAuth.
המטרה היא ליצור תשתית אינטגרטיבית סטנדרטית שתתאים לכל מערכת מידע רפואית, לא תלות בשפת הקוד שפותחה או בתשתית. ניתן להשתמש ב- FHIR במגוון יישומים, כולל אפליקציות סלולריות, תקשורת ענן, מערכות תיק מטופל EHRs, ועוד.
בארצנו הוטמעה מערכת אינטראופרבילית משמעותית כרשומה רפואית לאומית בשם מערכת איתן של משרד הבריאות, המאפשרת שיתוף והעברת מידע בין קופות החולים ובתי החולים. מדובר בשיתוף מידע קליני, המרכז את עיקרי המידע אודות המטופל מתוך התיק הרפואי, שמקורו בבתי החולים ובקופות החולים, כאשר בבתי החולים הצוות הרפואי מקבל הרשאה ספציפית, המאפשרת גישה למערכת מרגע הביקור של המטופל בבית החולים ולתקופת זמן מוגדרת אחריו.
בקופות החולים מתקבלות מדי יום סיכומי ביקור במיון ובאשפוז עבור כל מבוטחי הקופה שהשתחררו באותו יום מבית החולים.

המערכת מאד יעילה בתמיכת הצוות רפואי במחלקות מיון בקבלת מידע עבור חולים מורכבים ובמצבי חירום בהם האדם המטופל מתקשה או לא מסוגל למסור מידע בעצמו, בצמצום טעויות באבחון הנובעות מהיעדר מידע וקבלת החלטות קליניות טובות יותר בשילוב עם מערכות CDS Clinical Decision Support. לאחרונה גם שולבה באיתן מערכת צד שלישי המאפשרת צפייה בבדיקות דימות של המטופלים מכלל בתי החולים וקופות החולים. המערכת הוקמה תוך שמירה על כללי אבטחת מידע מחמירים, ללא מאגר מידע מרכזי של כללי אלא מבוססת על אחזור הנתונים משרתים מקומיים לפי דרישה של הצוות הרפואי בלבד.
Jacky Dahan

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

אינטראופרביליות בין מערכות רפואיות היא היכולת של מערכות המידע השונות והמגוונות לרבות ציודים רפואיים ויישומים רפואיים, לשתף מידע בצורה אינטגרטיבית בין מערכות פנים ארגוניות דרך מערכות חוצות ארגונים, ובכך לפרוץ את גבולות שמירת המידע במוסדות רפואיים באופן אינדיווידואלי לכיוון של שיתוף מידע באופן גלובלי חוצה גבולות ולאומים.
פיתוח הסטנדרטיים להקמת תשתיות וארכיטקטורות של שיתוף מידע רפואי, מאפשרת לשתף מידע בצורה מאובטחת ומבוקרת בין ארגוני בריאות שונים בספקטרום רחב שכולל, חברות ביטוח רפואי, בתי חולים, קופות חולים, מכונים פרטיים, מעבדות, משרדי בריאות עד לארגון הבריאות העולמי.
נכון להיום קיימות 4 רמות של אינטראופרביליות במערכות רפואיות:
רמה 1 בסיסית – היכולת לקיים תקשורת בסיסית מאובטחת בין מערכת מידע אחת למערכת מידע אחרת
רמה 2 מובנית – מגדירה את פורמט, התחביר והארגון של חלופי הנתונים עד לרמת שדות הנתונים, שנתונים לפרשנות ועדיין לא סטנדרטיים.
רמה 3 סמנטית – מספקת מודלים לשיתוף וקידוד נתונים, כולל שימוש בהגדרות קידוד סטנדרטיות בינלאומיות בעלות משמעות סטנדרטית קלינית למשתמש הקצה.
רמה 4 רגולטיבית – אופן שיתוף המידע כולל בתוכו שיקולים ממשלתיים, מדיניים, חברתיים, משפטיים וארגוניים בכדי לבקר על תקשורת הנתונים והשימוש המאובטח תוך שמירה על תזמון ושיתוף המידע בין הארגונים. פיקוח של ישויות אלו מאפשר הסכמה משותפת, אמון ובקרה על תהליכים בשילובם על המערכות ומשתמשי הקצה.
כיצד זה בא לידי ביטוי הלכה למעשה? ובכן, רב ארגוני הבריאות במדינות המפותחות כבר עומדים בסטנדרטיים של רמה 3 ונמצאים במגמה של התקדמות להשלמת רמה 4, יחד עם זאת חלק מהארגונים פיתחו סטנדרטיים היברידיים ייחודיים שעומדים באופן חלקי עם הסטנדרט שמכתיב ארגון ה IHE Integrating the Healthcare Enterprise העולמי.
בבלוג הבא אסקור את היתרונות והסטנדרטים במודל האינטראופרבילי.

Jacky Dahan

מערכות מידע לניהול המערך הרדיולוגי בבתי חולים, נקראות מערכות RIS ו PACS, כאשר הראשונה, Radiology Information System, מהווה תפקיד חשוב וקריטי בניהול יעיל ובטוח של המערך הרדיולוגי בבתי חולים בארץ ובעולם .
חלק חשוב בבחירת הספק הוא תהליך אפיון מפורט והתאמת המערכת לצרכי בית החולים, בנוסף מעורבות המשתמשים לרבות רדיולוגים, רנטגנאים, הנהלה ומזכירות מיחידות הדימות השונות הכוללים:
רנטגן קונבנציונאלי, אולטראסאונד, CT , MRI , ממוגרפיה ורפואה גרעינית, היא קריטית להצלחת פרויקטים מסוג זה,
בד בבד תהליך אפיון מפורט של האינטגרציה ופיתוח ממשקים רבים להעברת מידע בין המערכות כך שמערכת ה RIS-היא המערכת המרכזית המסונכרנת בראש ובראשונה עם התיק הרפואי הקליני של בית החולים ומערכת ה PACS לצפייה בצילומים שביצע המטופל, כמו כן ישנו שילוב של ממשקים רבים נוספות למערכות לוין המוטמעות בביתי החולים ביניהם:
· אינטגרציה למערכות לעיבוד בדיקות דימות מתקדמות
· מערכת תווכה ESB- Enterprise Service Bus לניהול תעבורת מסרים
בין מערכות המידע Modalities מכשירי דימות- לטובת העברת פרטים
קליניים, נתוני קרינה, נתוני
הזרקה ופרטים דמוגרפים בין ה RIS ל Modalities באופן דו כיווני.
· מערכת לזיהוי Voice to Text לפענוח מהיר של תשובה ללא תלות
בקלדניות
· אינטגרציה מערכות שליחים, לניוד מטופלים מאושפזים בין המחלקות
ליחידות הדימות
· קליטת תשובות פתולוגיה מהמעבדה הפתולוגית
· מערכות CRM במוקד קשרי לקוחות לסנכרון פרטי התורים
· לוחות חיתום דיגיטלי על טפסי הסכמה מדעת מערכותRIS מנהלות את
כלל תהליכי העבודה של מערך מכון הדימות ומאפשרת מעקב אחר
פעולות המבוצעות לנבדק במכון הדימות וההיסטוריה ההדמייתית של
הנבדק.
המערכת מאפשרת עבודה בתהליך רציף כשכל שלב בתהליך קשור בשלב שקדם לו בשרשרת:
זימון תורים, קבלת הנבדק, קביעת פרוטוקולים לבדיקות על ידי הרופאים הרדיולוגים, ביצוע הבדיקה על ידי הרנטגנאים, פענוח רדיולוגים, אדמיניסטרציה, שיוך הבדיקות השונות לרופאים בהתאם לתתי ההתמחות שלהם והפצת דוחות התשובה לקהילה.
תהליך זימון תורים שמתבצע הן במוקד קשרי הלקוחות והן במחלקות עצמן משלב תהליכי דיגיטל בענן AWS לשילוב הפניות ומסמכים רפואיים דרך טלפונים ניידים חכמים ישירות לתיק המטופל.
המשכו של התהליך בקבלת מטופל יעילה משולבת עם מערכת קבלה אדמיניסטרטיבית, לשמירת אחידות בפרטי המטופל ושלמות ההתחשבנות מול הגורמים המבטחים שונים.
המשכו במודול תמיכה בתהליך עבודתם של הרנטגנאים בשילוב רשימות עבודה אינטראקטיביות,
וסיומו בתהליך פענוח מהיר ויעיל של רופא רדיולוג כשהוא נעזר ברשימות עבודה מגוונות, תוך צפייה מהירה ונוחה בכלל הבדיקות שבוצעו והנתונים הקליניים אודות המטופל.
הרופא הרדיולוג יכול לצפות בבדיקות שבוצעו בתוך בית החולים והן מחוצה לו בשילוב מערכת "איתן - רשומה רפואית לאומית" והכל ממסך אחד מחולק לתתי חלונות שנותנים מבט של 360 מעלות, מינימום הקלקות ומעבר מהיר בין בדיקה לבדיקה בשילוב מערכת ה- PACS לצפייה בתמונות.
תיעוד התהליכים במערכת, מאפשר יצירה של דוחות סטטיסטיים מפורטים, כמו למשל, הספקי עבודה, ניצול חדרי בדיקה, זמני המתנה לתור, זמני המתנה לבדיקה, זמני פענוח ועוד. הניתוחים הסטטיסטיים מאפשרים התייעלות מתמדת בכלל תהליכי העבודה ובניהול רצפת הייצור של מערך הדימות.
מערכות RIS משולבות בכל מכוני הדימות הגדולים בארץ ובעולם והן חלק חשוב בביצוע בקרות האיכות של מכוני הדימות. ישנו הבדל מהותי בתהליכי העבודה של בתי חולים ציבוריים לבתי חולים ומכונים פרטיים כך שרמת המורכבות עולה בכל ההיבטים בסקטור הציבורי.
בתי חולים ומכונים רבים בארץ ובעולם נמצאים בתהליך של מעבר של מערכות לניהול מערכי דימות בפיתוח עצמי למערכות RIS כמוצר מדף רובסטי, עשיר ומגוון יותר פונקציונלית ומתפתח עם חכמת ההמונים, כך שמפיתוח של בית חולים אחד נהנים כלל בתי החולים והמכונים, כתוצאה מכך עלויות כ"א בפיתוחים יורדת, וכל זאת בהתאמה של מערכת ה RIS לסטנדרטים ותקינות רפואיות בינלאומיות.

Jacky Dahan

תפיסה כוללת

פוגענים מודרניים

תפיסת האבטחה באופן מובן חייבת להיות נגזרת מהאיומים החלים על הארגון. איומים אלה שונים מהותית מהאיומים הטכנולוגיים המוכרים כפי שהיו עד לפני כ- 3 שנים. איומים היום (כדוגמת Stuxnet, אירוע Target וכו׳) מאופיינים בצורה הבאה -
1. איומים מגיעים בקבצים - ההתקפות מתחילות ברוב המכריע של המקרים בקובץ אשר מגיע למשתמש תמים, אשר מפעיל אותו. הקובץ לאחר מכן משיג שליטה על המחשב של המשתמש והרשאותיו, ובעצם מתחיל בכך את ההתקפה.
2. הפוגען חייב לחצות את ה-Datacenter כדי להגיע מאותו משתמש תמים אל המידע אותו הוא מחפש. זאת ניתן לבצע באמצעות מגוון טכניקות הן ידועות והן Zero Day, אולם הן כולן מתבססות על תנועה ברשת תוך ניצול הרשאות הרשת הקיימות של המשתמש.
3. הפוגען חייב בדרך כל שהיא ״לצאת החוצה״, קרי Command & Control או C&C. אנו לא מכירים התקפה או אירוע אבטחה אשר ״הצליח״ ללא טכניקה זו. התקשורת הזאת יכולה להיות למטרת ״הברחת״ מידע החוצה, או לשם דיווח על השגת יעדים ו/או קבלת הוראות להמשך התקיפה והתנועה ברשת.
4. התקפה מוצלחת היא כזאת שכל השלבים בה התבצעו בהצלחה. זוהי שרשרת של התקפה. מספיק למנוע שלב אחד בהתקפה כדי למנוע את הצלחתה, או כדי למזער באופן דרסטי את הצלחתה.

Zero Trust

1. תפיסה זו אשר הוגדרה ע״י חברת Forrester, גורסת כי כל ישות ברשת היא קודם כל UnTrusted ולא סומכים עליה. לא מאפשרים לשום ישות רשת גישה או הרשאה, אלא אם כן זה אושר באופן פרטני.
2. הכינוי לגישה זו הוא Whitelist - כלומר הרשאות הן ברמה של מה כן מאפשרים, וכל השאר לא מאופשר.
3. זו למעשה הדרך היחידה לקיים אבטחת מידע באופן יעיל, והתפיסה הזו בסופו של דבר צריכה להיות מיושמת באופן פרטני עד כמה שניתן, בכל תשתית בנפרד.

ממשקים בין ״איים״

1. כאשר עובדים במודל Top-Down, האתגר הראשון מתעורר בקישור בין עננים שונים.
2. דוגמא לכך היא למשל קישור רשת א׳ לרשת ב׳, שכן אלו 2 ישויות אשר מנוהלות ע״י גורמים שונים, עם תפיסות אבטחה לא תמיד זהות.
3. בקישור מסוג זה יש לממש את תפיסת ה-Zero Trust ולאפשר אך ורק שירותים פרטניים אשר אכן נדרשים בפועל.
4. שאלה מהותית אשר עולה כאן, האם לאפשר אך ורק את השירות, או לאפשר שירות לגורם מסויים (כתובת IP או משתמש או קבוצת משתמשים).
5. כאן עולה השאלה, מכיוון שצד אחד אינו מנהל את הרשת בצד השני, האם יש משמעות לאותה כתובת IP או משתמש, שכן אין דרך לוודא כי זה אכן מייצג את מי שאנחנו חושבים שהוא מייצג.
6. יש לציין כי האישור הפרטני של שירותים ותכנים צריך להתבצע בצורה פרטנית ככל שניתן, ברמת טרנזאקציה, קובץ וכו׳, תוך הפעלת מגוון יכולות של זיהוי וסינון פוגענים, על כל פרוטוקול. ראו פרק ״דרישות הגנה מודרניות״.

מימוש ברשת הפיזית

1. זהו למעשה המימוש הקלאסי של אבטחת מידע ברשת - Network Security.
2. גם במקרה שבו כלל המשאבים והשרתים ברשת הם וירטואליים, בסופו של דבר קיימת גם רשת פיזית, ואותה יש לאבטחה בצורה מקסימלית.
3. הדגש המרכזי כאן הוא סגמנטציה מקסימלית, כלומר הפרדת שירותים וישויות עד כמה שניתן, בדר״כ באמצעות סגמנטים ו-VLANs, ומידור רשתי ביניהם.
4. יש לשים דגש על הפעלת כלל יכולות ודרישות האבטחה, בכל פרוטוקול ובכל שירות, ומידור ברמה פרטנית של טרנזאקציות וקבצים, ראו פרק ״דרישות הגנה מודרניות״.
5. דגש חשוב מאוד ביישום ברשת הפיזית היא קצבי התעבורה. באופן מסורתי עולם האבטחה אינו מסוגל לטפל בתוכן של פרוטוקולים מורכבים (קבצים ותכני הקבצים) בקצבים גבוהים. יש לכך סיבות מגוונות אך הדרישה לכך, לאור המאפיינים של האיום המודרני - שהינו תמיד מבוסס על קובץ - אין כל משמעות בביצוע Network Security אם לא נעשית סריקה מתקדמת של כלל הקבצים/תכנים בכל הפרוטוקולים, ויש לתת על כך את הדעת.ד

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

1. קיימים מספר אתגרי אבטחה ייחודים לשירותים המתארחים בתשתית וירטואלית, אשר מצטרפים אל אתגרי האבטחה ״הרגילים״.
2. האתגר הראשון הינו תעבורת רשת בין מספר שירותים המתארחים על אותה סביבה וירטואלית.
3. באופן אינטואטיבי, גם אם מיושם מערך אבטחת מידע רשתי טוב מאוד, תעבורה בין 2 שירותים וירטואלים אשר יושבים על אותו השרת הפיזי, לעולם לא יגיעו לרשת, ולכן לא יעברו את מנגנוני ההגנה שברשת.
4. תעבורה זו מכונה East-West Traffic.
5. האתגר השני הוא העובדה כי לכתובות IP של השירותים הירטואלים (Guest VMs) כמעט ואין משמעות. היכולת של גורמי System להוסיף שירותים חדשים ולהעביר (Migration) שירותים מסביבה פיזית אחת לשניה באופן קל ומהיר, גוררת במרבית המקרים שינוי של כתובות ה-IP.
6. כדי להתמודד עם קושי זה נדרשת יכולת לנהל מדיניות אבטחת מידע, וכן אכיפה של מערך ההגנה, ע״ב מאפיינים לוגיים של השירותים ולא ע״ב כתובות ה-IP.
7. בצורה זו מדיניות האבטחה תיושם תמיד ובאופן שוטף, למעשה ללא ידיעה מוקדמת אודות כתובות ה-IP של השירותים הוירטואליים.

Micro Segmentation

1. היתרון המשמעותי בהיבטי אבטחת מידע של הרצת שירותים בסביבה וירטואלית הוא ביצוע Micro Segmentation. תפיסה גורסת כי כל שרת ולעיתים כל שירות מקבל למעשה סגמנט עצמאי משלו. תפיסה זו מאפשרת ליישם אבטחה מקסימלית, שכן כל שירות ממודר לחלוטין משירותים אחרים ומוגן באופן מקסימלי.
2. הגמישות של תשתית וירטואלית טובה מאפשרת לבצע Micro Segmentation באופן יחסי פשוט, בעוד שבסביבות פיזיות לא ניתן כלל לבצע זאת, שכן עלות התפעול גבוהה מאוד.
3. כאשר באים ליישם אבטחת מידע סביב תפיסת Micro Segmentation, הקושי התפעולי העולה הינו הצורך בממשק ישיר בין תשתית האבטחה לבין התשתית הוירטואלית. הדרך היחידה בה תפיסה כזו תעבוד באופן יעיל, היא כאשר ניהול מדיניות האבטחה (Security Policy) מנוהל ע״ב מאפיינים לוגיים של השירותים, ולא ע״ב כתובות IP, שכן לאלו כמעט ואין משמעות.

דרישות הגנה מודרניות

1. בהינתן המאפיינים של פוגען/איום מודרני, יש לשנות את יכולות ודרישות ההגנה והמידור כך שיתאימו.
2. העובדה שאיום מתחיל תמיד כקובץ, הרי שאנו נדרשים לכל הפחות ״לדעת״ על קיומו של קובץ, ורצוי גם סוג הקובץ, השם שלו וה-Hash שלו, בכל פרוטוקול ובכל שירות שפועל ברשת.
3. בצורה זו ניתן גם להגדיר הגדרות המאפשרות רק סוגי קבצים מסויימים ברשת, כלומר למשל לאפשר רק קבצים MS-Office ו-PDF ולחסום קבצי EXE, DLL, APK וכו׳, ובכך להקטין בצורה דרסטית את היכולת לממש התקפה. כמו כן ברגע שקיימת יכולת כזו ניתן לתשאל את המערכת ולראות למשל איזה קבצים העביר המשתמש # # בחודש האחרון. יש לציין כי ליכולת זו יש משמעות אך ורק אם היא פועלת על כל הפרוטוקולים והשירותים אשר בהם נעשה שימוש.
4. השירותים המאופשרים ברשת, מאופשרים כיום ברמת Layer-4, כלומר כתובות IP ו-TCP/UDP Ports. יכולת זו היא מנווונת מאוד ומאפשר בקלות מעקף, שכן אמצעי ההגנה מסתכלים אך ורק על הפורט עצמו, ולא על התוכן. חשוב לממש את יישום תפיסת ההגנה והמידור באמצעות תוכן השירות עצמו - למשל לאפשר אך ורק טרנזאקציות ספציפיות של MS-Lync, ללא שירות העברת הקבצים של המוצר, בהתעלמות מוחלטת מהפורטים (שלמעשה אין להם שום משמעות).
5. בדיקת איומי Zero Day - אחד האתגרים הגדולים היום הוא שמרבית מוצרי האבטחה מבוססים על חתימות. כלומר חברת האבטחה מייצרת חתימה לאיום שחקרה במעבדה שלה, וכך אנו מוגנים מפני איום זה, אולם מה קורה במקרה שבו הפעם הראשונה שבו איום מופיע הוא ברשת הצבאית? במקרה זה לא יכולה להיות לכך חתימה.
6. קיים כיום קונספט אשר נקרא Sandboxing, אשר מאפשר להריץ קובץ בלתי מוכר בזמן אמת ב-VM, כדי לראות מה ההתנהגות שלו בפועל, ועפ״י התנהגותו מתקבלת החלטה בזמן אמת האם הוא תקין או פוגען. במקרה שמדובר בפוגען ניתן הן לחסום את הקובץ עצמו, וחשוב מכך, לחסום באופן דינמי את ההתנהגות שלו ואת טכניקות ההתפשטות שלו, בכלל מנגנוני האבטחה ברשת.
7. כפי שתואר, החלק האחרון בכל התקפה הוא C&C. טכניקות C&C מבוססות בעיקר על העובדה כי מרבית טכנולוגיות ההגנה מבוססות על פורטים ברשת. מספיק שנשלח SSH Tunnel בפורט לגיטימי כגון 53 (אשר משמש בדר״כ ל-DNS), כדי שלא ניתן יהיה לזהות טכניקה זו.
8. אי לכך חשוב מאוד לבסס את יישום תפיסת ההגנה והמידור ברשת על תוכן השירות, הטרנזאקציה הנדרשת והתוכן שלה, ולא על מאפייני רשת שאין להם משמעות
ושקל מאוד לעקוף אותם.

מצורף מאמר הסוקר את סוגיות אבטחת המידע ב - SDDC

אבטחת מידע ב-Software Defined Data Center

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

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

קיימים פתרונות הפותרים בעיה זו באמצעות שכבת הרשת, כך ניתן באמצעות VLANs ו-VXLANs לפתור זאת, אולם הפתרון הוא מורכב מאוד ואינו ישים בפועל בארגוני Enterprise.

פתרונות האבטחה הייעודים לסביבות וירטואליות הקיימים כיום מבוססים על תפיסות Legacy כגון Layer-4 Firewall ו-IPS בלבד. אלו יודעים במקרה הטוב לבדוק פורטים וכתובות IP וכן חתימות של התקפות ידועות מראש. פתרונות אבטחה אלו פשוט אינם מתאימים להתקפות המודרניות שאנו רואים כיום, בעיקר לאלו המכונים APTs.

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

בשורה התחתונה אנו רואים כי במרבית ארגוני ה-Enterprise שכבת ה-Network Security הופכת לגורם אשר מעכב ופוגע בסביבות השרתים הוירטואליות והדינמיות, ולארגון קשה ליישם את מדיניות האבטחה שלו ללא תשלום ״קנס״.

זאת הסיבה שחברת Palo Alto Networks החליטה לשתף פעולה באופן אסטרטגי עם חברת VMware וכן עם חברות וירטואליזציה ו-Cloud נוספות, כדי לתת מענה מתאים לאתגרים הללו.
לפני מספר שבועות הכרזנו על אינטגרציה מלאה עם VMware NSX, באמצעות מודל ייחודי של הפלטפורמה שלנו - HV-1000-VM אשר תוכנן ייעודית עבור פלטפורמת ה-NSX של VMware. מודל זה יודע גם לעבוד בתצורת Standalone עם VMware ESXi וכן עם Citrix SDX.

תודות לאינטגרציה הנ״ל אנו יודעים להביא את יכולות ה- Next Generation Network Security שלנו לעולם הוירטואלי, תוך התממשקות מלאה ליכולות הניהול הקיימות בעולם הוירטואלי, בדגש על יכולות הניהול של VMware vSphere ו-NSX Manager. יכולות הניהול הללו מאפשרות ניהול חוקת אבטחה אשר מבוססת ב- 100% על ה-context והמידע המגיע מ-VMware, כך שכל שרת וירטואלי חדש וכל migration של שרת בין סביבות וירטואליות מקבל באופן אוטומטי את חוקת האבטחה הרלוונטית אליו, בהתבסס על קונפיגורצית VMware, ללא צורך בעדכון והגדרת חוקי אבטחה ידניים וללא צורך בהגדרות מבוססות IP ו-Ports.

מדוע היכולות הללו מהותיות עבור השוק?
בפעם הראשונה ניתן להפעיל את אותה רמת אבטחה שידענו לתת בעולם הפיזי בסביבות וירטואליות ובסביבות Cloud. כל פלטפורמות הוירטואל שלנו מריצות את אותה מערכת הפעלה OS-PAN שלנו, ללא יוצא מן הכלל. יכולות ה-Safe Application Enablement ו-Advanced Threat Prevention שהכרתם ממערכות ההגנה הפיזיות שלנו פועלות בצורה זהה גם כאן, ולמעשה מאפשרות גם הפעלת Security Policy אחד ויחיד, הן עבור סביבות הוירטואל והסביבות הפיזיות, וכן חוקה אחת עבור כל יכולות ההגנה, ללא צורך בהגדרות נפרדת עבור Firewall, Application, IPS, AntiVirus, Sandbox וכו׳.

הדרך האלגנטית בה יישמנו את הפתרון מאפשר הפרדת רשויות אמיתית בצד הניהול. אנשי האבטחה וה-IT מנהלים חוקי אבטחה המבוססים על אפליקציות, משתמשים ותוכן, אשר חלים על אובייקטים של VMware ,בעוד מנהלי השרתים הוירטואלים ומנהלי ה-Cloud מגדירים את הרכיבים הוירטואלים בכלי ה-Context של VMware (Tags, Containers) - השאר מבוצע באופן אוטומטי באמצעותנו. בצורה זו אין התנגשות בין ניהול הסביבה הוירטואלית לבין ניהול חוקי האבטחה - המערכת דואגת לאינטגרציה ביניהם באופן אוטומטי.

לאחר שסקרנו את המגמות הנוגעות לשוק העבודה וההתאמות המצופות מצד החברות והמעסיקים אסקור את ההשפעות על וההתאמת הנדרשות מצד המועסקים.
לאחר שהורגלנו להיות מסווגים "כחיוניים" או "לא חיוניים" ניכר כי הדבר התווה את הדרך אשר בה אנו נשווק או משווקים את עצמנו.
האם נכון הדבר? האם אנו צריכים לעשות התאמות אשר ישנו לחלוטין את התכונות והכישורים אשר השקענו בהם שנים רבות והביאו וקידמו אותנו לתפקידים אשר בהם אנו מכהנים?
מאחר וארגונים מסורתיים רבים רואים בהתייעלות ביטול משרות ניהוליות ופרויקטים אשר אמורים להביא את הארגון לקדמה טכנולוגית (מטיב "הלא חיוני") ניכר כי הדבר "הנכון" לעשות הוא להוכיח את יעילותך בביצוע משימות "חיוניות" ופחות בפרויקטים או משימות אשר ימנפו את הארגון ליצירת ערך.
ארגונים אשר הוקמו על טהרת אספקת שירותים דיגיטאליים המיצרים ערך עבור לקוחותיהם (בנקים דיגיטאליים, חברות Payments, שירותי Tele Health, חנויות דיגיטאליות וכיוצא באלה) ממשיכים להשקיע ביתר שאת בפיתוח יכולותיהם ובגיוס משאבים אשר יספקו להם יתרון על פני מתחריהם.
המניע החזק ביותר של האדם לביצוע פעולה הוא הפחד. הפחד מאיבוד מקום העבודה, פרנסה, הערך העצמי ושאר אלמנטים מובנים אשר מניעים אותנו לביצוע פעולות (לא תמיד מושכלות) בשם הפחד.
הפחד/החשש מהשינוי מביא אותנו לביצוע פעולות חיוביוית כגון למידה, התפתחות ונקיטת יוזמות שכנראה לא היינו מבצעים אם הוא לא היה נכפה עלינו.
לכן עלינו לתעל את יכולותינו המובנות לביצוע התאמות למציאות החדשה ולאו דווקא לנקוט בביצוע שינויים מרחיקי לכת אשר אינם קשורים ליכולותינו ולשאיפותינו.
הייתי מצפה כי מי שעוסק בבריאות ובספורט יציע את שירותיו גם בערוצים הדיגיטאליים( (YouTube או אף שיפתח חנות ב- Amazon ולא בהכרח שיהפוך להיות בלוגר או TikToker כי "עושים מזה כסף" בעת הזו.
מנהל חדשנות אשר כישוריו אינם נדרשים עוד בארגון אשר סבור כי קיצוץ בתחום זה הוא הדבר הנכון לעשות בעת הזו, יתאזר בסבלנות וימצא עבודה בארגון אשר יעריך את כישוריו ויכולותיו. בינתיים בזמן זה שישקיע בשיפור הידע וההשכלה בתחומים אשר לא היה לו זמן להשקיע בשנים שעבד ואולי אף לפתוח קבוצת מנהלי חדשנות ולהפיץ בה תכנים מעניינים (יכולה להוות מקור הכנסה נוסף בעתיד). זאת מכיוון שזו הדרך אשר בחר, זה העיסוק אשר גורם לו לסיפוק וזו הדרך הנכונה להמשיך בה גם בעתיד.
המסר אותו אני רוצה להעביר הוא שלמרות התקופה אשר מאלצת אותנו לבצע שינויים, עלינו להבחין בין ביצוע שינויים אשר אינם תואמים את יכולותינו ושאיפותינו כגון רציה חברתית או "לשחות שחיה עם הזרם", לבין שינויים אשר אנו מאמינים ביישומם, תואמים את כישורינו ושאיפותינו והמשתלבים במפת הדרכים אשר התוונו.

Sharon Haris