מה ארגון צריך כדי להפעיל מערכת כזו — On-Prem מול SaaS

השאלה כמעט אף פעם אינה «ענן או לא ענן». היא שתי שאלות נפרדות שנוטות להיבלע זו בזו: מי מפעיל את המערכת, ובתוך איזו דיירות היא יושבת. אוצר המילים הקיים לכך הוא של NIST: פרסום SP 800-145 מגדיר שלושה מודלי שירות (SaaS · PaaS · IaaS) וארבעה מודלי פריסה — פרטי, קהילתי, ציבורי והיברידי. ענן פרטי שהבנק מפעיל בעצמו אינו נופל לאף צד של הבינאריות שבכותרת, וזו בדיוק הנקודה.

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

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

1 · מה שנדרש עוד לפני שמדברים על חומרה

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

א. אנשים ותפקידים

מה נדרש	למה	מקור
מנהל טכנולוגיית המידע ומנהל הגנת הסייבר ואבטחת המידע, בשמות — ודיווח למפקח על מינוי ועל עזיבה צפויה	זו חובת דיווח, לא נוהג	364 §26, §34, §171.2–171.3
מאשר שינויים מוגדר, ומאשר נפרד לשינויי חירום	ההוראה דורשת במפורש לציין מי מוסמך לאשר שינוי חירום	364 §97
הפרדת תפקידים: מי שמבצע את השינוי אינו מי שמאשר אותו	מנוסח כדרישה, לא כהמלצה	364 §81, §124.2
כוננות עם סמכות להחליט, לא רק להסלים	מסלול חירום שאין בו מי שמוסמך להכריע בשתיים בלילה אינו מסלול	נגזרת תפעולית מ‑364 §97, לא לשון ההוראה
היכולת הפנימית להפעיל את הפונקציה גם כשהיא במיקור חוץ	«קליפה ריקה»	EBA/GL/2019/02 · 362 §25(ב)
בעלים בשם למערכת הזו עצמה, נפרד מבעלי המערכות שהיא מתארת	מרשם בלי בעלים מתיישן	קביעה שלנו, לא של תקן — הרקע ב‑NIST 800‑40r4 §3.2

ב. תהליך

מה נדרש	מקור
מדיניות טלאים ששעונה נגזר משני משתנים — חומרת הטלאי וגם קריטיות הנכס — ולא מלוח שנה שטוח	364 §61.4
סביבה נפרדת לבדיקה, וראיה שהטלאי אכן עבר בה	364 §61.4, §81
מסלול חירום מוגדר, עם גורם מוסמך לאשר	364 §97
נתיב ביקורת של הפעולות שבוצעו במהלך השינוי	364 §98
קבוצות תחזוקה במקום רשימת חריגים; חריג שבכל זאת קיים — נרשם ונסקר מחדש	NIST 800‑40r4 §3.4, §3.5.5
חלונות ההשבתה רשומים כתכונה של הנכס, לא בזיכרון של מישהו	NIST 800‑40r4 §3.2, §3.4
מדדים שחוצים חשיבות חולשה × חשיבות נכס, עם זמן עד היעד	NIST 800‑40r4 §3.6
שאלון רכש לספק: קצב טלאים, אופק תמיכה, יכולת החזרה לאחור	NIST 800‑40r4 §3.7

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

ג. נתונים — התנאי המוקדם שהכי מזלזלים בו

מה נדרש	מקור
תהליך לזיהוי כל נכסי המידע, מיפוי שלהם ושמירה על עדכניותו — לרבות אלו המנוהלים באמצעות צד ג׳	364 §43.2
זיהוי ותיעוד של הקשרים בין נכסי המידע, במפורש כדי לסייע בתגובה לכשל טכנולוגי ולאירוע אבטחת מידע	364 §43.2
סיווג הפעילויות העסקיות, התהליכים התומכים והנכסים במונחי קריטיות ורגישות	364 §43.3
נתוני תצורה (מודל, גרסה, מפרט) שנסקרים ומאומתים על בסיס שוטף — לא טבלה שמישהו מילא פעם	364 §61.2
אוטומציה, לא סריקה חודשית או רבעונית	NIST 800‑40r4 §3.2
מאפיינים עסקיים לכל נכס: מי מתחזק אותו, איזה דדליין חוקי חל עליו, אילו מגבלות חוזיות יש על עדכונו, ומתי מותר לאתחל אותו	NIST 800‑40r4 §3.2
מקור סמכותי אחד לשאלה «של מי המערכת הזו» — ותשובה אחת לכל שרת	קביעה שלנו. אין תקן שאומר את זה, וזו הבעיה הקשה ביותר שנתקלנו בה בפועל

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

"That model should no longer be used." — NIST SP 800‑40r4 §3.2

ד. טכני

מה נדרש	הערה
זהות: AD/LDAP, או מסלול מתועד למשתמשים מקומיים היכן שאין בקר תחום	ברשת מנותקת אין ספק זהות בענן — ראו סעיף 6
SMTP ששולח בפועל. בדיקת חיבור אינה מוכיחה שדואר יוצא	הראיה היחידה למסלול דואר היא דואר שהגיע
תעודות, ובעלים אנושי לתאריך החידוש שלהן	ראו סעיף 6
בסיס נתונים שמידותיו נגזרות מנפח ומתקופת שמירה, עם תקציב IOPS מוצהר	ראו סעיפים 3 ו‑7
גיבוי עם בדיקת שחזור תקופתית, מאוחסן מרוחק מספיק מהאתר הראשי, ומתוכנן לשרוד גם ניסיון לפגוע באמינות הגיבויים עצמם	364 §61.5.1–61.5.2
ניטור שמזהה אירוע בזמן אמת	364 §58.1.1, §58.1.4 · ובענן: 362 §34
נתיבי רשת מפורשים — ובמודל ענן, גם היכולת לנתק אותם בחירום	362 §30(ט)
תכנון קיבולת שמעריך את ביצועי הספק בשילוב עם שלכם	364 §61.6.6

ה. ממשל

מה נדרש	מקור
נתיב ביקורת שמכיל את זיהוי הגורם הניגש, המקור, הזמן ופרטים על נשוא הגישה	364 §61.7.1
הגנה על הנתיב מפני שינוי או מחיקה בלתי מורשים, ותקופת שמירה שנקבעת לפי קריטיות, רגישות ודרישות הדין — ההוראה נוקבת ב״פרק זמן הולם״ ולא במספר	364 §61.7.3
חיוב חוזי של צד ג׳ בהעברת קבצי Log לפי דרישה	364 §61.7.5
הסדרים חוזיים למחיקת הנתונים שלכם המאוחסנים אצל הספק, גם אצל קבלן המשנה שלו	364 §61.8.3 · 362 §30(א)
תוכנית יציאה — בענן, נסקרת אחת לשלוש שנים	362 §31(ה) · EBA §§106–108
זכות לקבל את המידע שהועבר, לרבות ביקורות אצל הספק, ולשתף אותו עם המפקח על הבנקים לפי דרישה	362 §30(ד)
תיעוד הארכיטקטורה והממשקים של השירות, שמתעדכן בכל שינוי ונבדק תקופתית	362 §26(ג), §27

לקוראים שממפים בין מסגרות: ב‑CIS Controls v8.1 הנושאים האלה מרוכזים בבקרות 1 (Inventory and Control of Enterprise Assets), 2 (Inventory and Control of Software Assets), 4 (Secure Configuration of Enterprise Assets and Software), 7 (Continuous Vulnerability Management), 8 (Audit Log Management), 11 (Data Recovery) ו‑15 (Service Provider Management). ב‑ISO/IEC 27001:2022 הבקרות המקבילות הן A.8.8, A.8.9 ו‑A.8.32 — מובאות כמצביע בלבד: הטקסט של התקן מורשה, ואי אפשר לצטט אותו כאן.

2 · שני סעיפים שכדאי לקרוא מדויק

מתוך הוראה 364, גרסת 11/24 (חוזר 2799):

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

בפסקה אחת יש שלוש דרישות נפרדות, וכל אחת מהן נבדקת בנפרד:

1. שעון שנגזר משני משתנים

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

2. בדיקה בסביבה נפרדת, לפני הייצור

   הדרישה קלה לניסוח וקשה להוכחה. העובדה שהטלאי נבדק צריכה להיות רשומה ליד החלון שבו הוא עלה לייצור — אחרת אין דרך להראות אותה בדיעבד.

3. מסלול חירום מוגדר

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

ולצידם, סעיף 98:

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

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

הפרדת הסביבות והפרדת התפקידים כתובות בנפרד. סעיף 81 מחייב הפרדה פיזית או לוגית בין סביבת הייצור לסביבות שאינן ייצור, «על מנת להבטיח הפרדת תפקידים נאותה וכדי למנוע הכנסת שינויים שלא אושרו לסביבת הייצור»; סעיף 124.2 דורש הפרדת תפקידים «במטרה למנוע מהעובדים להטמיע שינויים עצמאיים בסביבת הייצור».

3 · דרישות חומרה — איך ספקים רציניים מפרסמים את זה

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

הדוגמה הקרובה ביותר: נכסים × תקופת שמירה

Tenable Security Center הוא הספק היחיד בקבוצה הזו שמפרסם דיסק כפונקציה של שני הצירים שרלוונטיים למוצר מרשם — כמה נכסים, וכמה היסטוריה שומרים. סריקות בסיס ובדיקות מקומיות:

כתובות IP פעילות	CPU	זיכרון	דיסק ל‑90 יום	דיסק ל‑180 יום
2,500	8 ליבות @ 2GHz	16GB	130GB	260GB
10,000	16 ליבות @ 3GHz	32GB	450GB	900GB
25,000	32 ליבות @ 3GHz	64GB	2.4TB	5TB
100,000	48 ליבות @ 3GHz	96GB	4.5TB	9TB

הוספת מחלקת נתונים שנייה (ביקורת תצורה) מכפילה בקירוב את הדיסק בכל אחת מהשורות, בלי לשנות את מספר הנכסים. Tenable גם מפרסם אילוץ אחסון מפורש — אחסון מקומי או SAN בהשהיה של 10 מילישניות ומטה, NAS אינו נתמך — ונוסחת גידול: (גודל המאגר) × (ימי מגמה) × (מקדם גידול).

מה נשבר ראשון, לפי מי שמדד

Microsoft Configuration Manager פותח את דף הסיזינג שלו בהצהרת התזה:

"This article focuses on the largest contributor to Configuration Manager performance bottlenecks: the disk input/output subsystem or IOPS."

לקוחות שולחניים	ליבות	זיכרון	IOPS ל‑SQL	אחסון
25,000	6	24GB	1,700	350GB
50,000	8	32GB	2,800	600GB
100,000	12	64GB	5,000	1,100GB
150,000	16	96GB	7,400	1,600GB

ומשם שתי אמירות ששוות יותר מהטבלה. הראשונה: המוצר עובד טוב יותר עם 16 ליבות מהירות מאשר עם 24 איטיות, ופחות מ‑3–4GB זיכרון לליבה מוריד את כושר העיבוד הכולל. השנייה, וזו החשובה: ההגדרות שלכם הן משתנה סיזינג. מי שרוצה לאסוף מלאי חומרה בתדירות כפולה מברירת המחדל צריך לתכנן את החומרה כאילו יש לו פי שניים לקוחות.

הצורה של הקפיצה

ארכיטקטורות הייחוס של GitLab מפרסמות שבע שכבות, כל אחת מסומנת גם בעומס וגם במשתמשים. השכבה הקטנה ביותר היא מכונה אחת, 8 vCPU ו‑16GB; השכבה של 200 בקשות לשנייה היא כשלושים מכונות מפוצלות לתפקידים. מה שקנו בדרך הוא בעיקר זמינות, לא תפוקה — הסף שהם מפרסמים למעבר לארכיטקטורת HA הוא 3,000 משתמשים, ומקבץ בסיס נתונים עם רפליקציה ו‑failover דורש לפחות שלושה צמתים. זו הצורה האמיתית של פריסה מקומית, וכדאי שצוות התשתיות יראה אותה מוקדם.

הדוגמה הנגדית מועילה בדיוק באותה מידה: מדריך הסיזינג של Jira Data Center מודד תשעה ממדים של תוכן — כרטיסים, פרויקטים, שדות מותאמים, תהליכי עבודה — ומחלק לארבעה פרופילים, אבל אינו מפרסם ולו מספר CPU, זיכרון או דיסק אחד. הקורא יוצא משם בלי מספר. זו תבנית אמיתית ומפורסמת, והיא החלשה מבין השתיים.

4 · ההחלטה עצמה — אחד‑עשר צירים

ציר	הפעלה עצמית	שירות מנוהל	המקור שהופך את זה לשאלה
תושבות ושליטה במידע	המידע אינו יוצא	העברה לחו״ל מוסדרת בתקנות	תקנות הגנת הפרטיות (העברת מידע אל מאגרי מידע שמחוץ לגבולות המדינה), תשס״א‑2001 · 362 §30(ו)
רשת מנותקת	אפשרי	לא אפשרי לכל מה שדורש מישור בקרה חי	סעיף 6 להלן
תיעוד רגולטורי	מתעדים ארכיטקטורה אחת	מתעדים גם את של הספק	362 §26(ב), §26(ג), §27
שדרוגים — מי מחליט, מי אחראי	אתם בוחרים מתי, ואתם בעלי הרגרסיה	הספק בוחר, ואתם בעלי הקבלה	ServiceNow · Atlassian (להלן)
צורת העלות	הון‑כבדה, עם זנב ארוך	תפעולית — אבל ליציאה יש מחיר	מונים שורות עלות, לא מספרים (להלן)
עומס כוח אדם	אתם מעדכנים גם את מערכת ניהול העדכונים	הספק	NIST 800‑40r4 §3.1 · טבלאות הסיזינג בסעיף 3
גיבוי והתאוששות	שלכם	חוזי, ונדרש לוודא שהוא אכן מתבצע	364 §61.5.1–61.5.3 · 362 §30(ח)
ממשקים אל AD/LDAP, CMDB, SIEM	ישירים	דורשים נתיב יציאה או מחבר	סעיף 6 להלן
תגובה לאירוע וגישה לתמיכה	ה‑SOC שלכם, הלוגים שלכם	צריך לעגן בחוזה את קבלת הלוגים	364 §61.7.5 · 362 §34
יציאה וניידות	להעביר בסיס נתונים	להעביר דיירות — ולהוכיח שאפשר	EBA §§106–108 · 362 §31(ה) · 364 §58.1.5
אחריות	שלכם	עדיין שלכם	362 §25(ב) · EBA

הטיעון החזק ביותר נגד הפעלה עצמית, ממקור ניטרלי

NIST SP 800‑40r4 מונה שיטות להקטנת מספר החולשות שארגון נדרש לטפל בהן. אחת מהן כתובה כך:

"Use managed services instead of software when feasible." — NIST SP 800‑40r4 §3.1

ובאותו סעיף:

"Organizations should consider deploying applications in ways that make patching less likely to disrupt operations. One example is to run applications on stacks or platforms where patching is a fundamental part of the deployed technology and is less likely to disrupt operations…"

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

והטיעון שמגביל אותו

ההנחיות של ה‑EBA למיקור חוץ (EBA/GL/2019/02, בתוקף מ‑30 בספטמבר 2019) אינן חלות על תאגיד בנקאי בישראל, ומובאות כאן כמסגרת מפורסמת מרשות אחרת שנוח להשתמש בה כרשימת בדיקה. המשפט המרכזי שלהן:

"Outsourcing must not lead to a situation in which an institution becomes an 'empty shell' that lacks the substance to remain authorised."

הן גם דורשות תוכנית יציאה מתועדת לפונקציות קריטיות, שמביאה בחשבון גם כשל של הספק ולא רק סיום חוזה מוסכם (§106); שתהיה נבדקת ומתומחרת — ניתוח של העלות, ההשפעה, המשאבים והזמן שיידרשו למעבר לספק חלופי או חזרה פנימה (§107); ושיוגדרו לה מדדים שסף אי‑עמידה בהם מפעיל את היציאה (§108). תוכנית יציאה שלא תומחרה היא כוונה, לא תוכנית.

שתי עובדות שוק, שתיהן לא נוחות

קו מוצר מקומי יכול להיסגר תחתיכם. התמיכה ב‑Atlassian Server הסתיימה ב‑15 בפברואר 2024; מאותו מועד המוצרים אינם זכאים לחידוש ואינם מקבלים עדכונים, שיפורים או טלאי אבטחה.

וגם ההפך קורה. ServiceNow השיקה מחדש פריסה בשליטת הלקוח בשם Private Stack, במפורש עבור סביבות ריבוניות, מנותקות ומוסדרות, ובכללן בנקאות. חלוקת האחריות מוצהרת: הלקוח מחזיק את החומרה, בסיס הנתונים, מאזני העומס, הרשת ומערכת ההפעלה; הספק מספק את התוכנה, הנחיות הפריסה, חבילות השדרוג והתמיכה. והחלק שהופך את זה לעדות שימושית — הם פרסמו את רשימת היכולות שאין בפריסה המקומית, ולא רק את מה שיש.

על עלות, בלי מספרים

Gartner מפרסמת ערכות TCO ייעודיות להשוואה הזו, והן מאחורי תשלום. שום אחוז חיסכון, יחס או שנת איזון אינו מודפס כאן, כי אין לו מקור ראשוני שאפשר להצביע עליו. מה שכן אפשר לומר הוא אילו שורות עלות כל מודל יוצר: הפעלה עצמית יוצרת שורות שאין בשירות מנוהל (חומרה, רישוי מערכת הפעלה והיפרוויזור, רישוי בסיס נתונים, חשמל ושטח, זמן האנשים שמעדכנים את מערכת ניהול העדכונים, מדיית גיבוי, אתר התאוששות); שירות מנוהל יוצר שורות שאין בהפעלה עצמית (מנוי, אינטגרציה ותעבורה, תמחור תוכנית היציאה שה‑EBA דורשת, והיכולת הפנימית שחייבים להחזיק בכל מקרה). שני המודלים יוצרים שורה שרוב מסמכי ההצדקה שוכחים: עבודת איכות הנתונים מסעיף 1.ג.

5 · ההקשר הרגולטורי, לפי מה שההוראות באמת אומרות

5.1 · הוראה 364 כבר כתבה את רשימת הבדיקה לצד ג׳

364 נחתמת בנספח — «הנחיות לניהול סיכונים מול צדדים שלישיים» — שמרכז 22 מקומות בגוף ההוראה שבהם צד ג׳ נדרש להיכנס לשיקול. זו רשימת הבדיקה של המפקח, לא של ספק:

#	נושא	סעיף
1	חובת הדירקטוריון להתייחס בדיוניו להיבטי שימוש בצד ג׳	§18
2	זיהוי ומיפוי כל נכסי המידע, לרבות המנוהלים באמצעות צד ג׳	§43.2
3	תוכנית הדרכה והגברת מודעות	§53
4	החוסן התפעולי של סביבת ענן המשמשת לאספקת פעולות חיוניות ללקוחות	§56.2
5	התשתית הטכנולוגית המנוהלת על ידי צד ג׳	§58.1
6	תהליך הגיבויים	§61.5.3
7	היבטי קיבולת	§61.6.6
8	העברת קבצי Log	§61.7.5
9	הסדרים למחיקת נתונים המאוחסנים אצל צד ג׳	§61.8.3
10	תהליך התכנון וההשקעה בטכנולוגיית המידע	§64.2
11	תהליך ניהול הרכישה של מערכת	§§75–78
12	פיתוח API	§§84–91
13	הערכת יכולת אבטחת מידע	§102
14	מסגרת לניהול אבטחת מידע והגנת הסייבר	§103
15	מדיניות אבטחת המידע והגנת הסייבר	§§106.12–106.13, §107
16	יישום בקרות אבטחת מידע על נכסים המנוהלים באמצעות צד ג׳	§§109–110
17	בקרות ניהול שירותי צד שלישי	§114.12
18	בקרות גישה פיזית ובקרות סביבתיות	§122
19	הערכת אפקטיביות הבקרות על נכסים המנוהלים באמצעות צד ג׳	§140
20	שיתוף פעולה ותיאום מול צד ג׳ בעת אירוע	§146.10
21	תוכנית התאוששות מאסון	§165
22	בדיקה ותרגול של תוכניות ההתאוששות	§168.1

ההוראה עצמה מסייגת את הנספח: הריכוז מובא לנוחות הקורא, ובכל מקרה של סתירה בין הנספח לבין גוף ההוראה — גוף ההוראה קובע.

5.2 · הוראה 362 — מה שהחוזה חייב להכיל

הוראה 362 «מחשוב ענן», בגרסה שנבדקה — (06/22) [4] — חלה על «מחשוב ענן מהותי» (§28 קובע שהפרק אינו חל על מחשוב ענן שאינו מהותי). מה שרלוונטי לקורא של דף זה:

• §29 — בדיקת נאותות, לרבות עמידת הספק בדיני הגנת הפרטיות במדינה שבה הוא פועל.
• §30(א) — מחיקת המידע ממערכות הספק, עם הבטחה שלא ניתן לאחזרו.
• §30(ד) — היכולת לקבל את המידע, לרבות ביקורות אצל הספק, ולשתפו עם המפקח.
• §30(ו) — מיקום מתקן הענן והאחסון, והתחייבות להודעה מראש על שינוי.
• §30(ח) — גיבוי ואפשרות אחזור.
• §30(ט) — היכולת להפעיל או לנטרל שירות מהותי, לרבות חסימת גישה, בחירום.
• §31(ה) — תוכנית יציאה, שנסקרת ומתעדכנת אחת לשלוש שנים.
• §33 — הצפנה במעבר ובמנוחה; היכן שקשה להצפין הכול — לכל הפחות המידע הרגיש.
• §34 — יכולת ניטור מלאה ורציפה בזמן אמת, לזיהוי מוקדם של אירוע סייבר.
• §26(ג) ו‑§27 — תיעוד מיפוי הארכיטקטורה, הממשקים ודרישות אבטחת המידע, ועדכונו בכל שינוי ובאופן תקופתי.

5.3 · כלל הסתירה — התשובה לשאלה «האם מעבר לענן מרפה משהו»

מיד לאחר סעיף 61.8.3 כותבת הוראה 364:

בכל מקרה של אי תאימות בין דרישה זו לבין הדרישה המופיעה בסעיף 30(א) להוראת ניהול בנקאי תקין מס׳ 362 בנושא: "מחשוב ענן" … תחול הדרישה המחמירה מבין שתיהן.

לא מרפה. במקום שבו שתי ההוראות אומרות דברים שונים, המחמירה גוברת.

5.4 · תושבות נתונים

תקנות הגנת הפרטיות (העברת מידע אל מאגרי מידע שמחוץ לגבולות המדינה), תשס״א‑2001, בתרגום הלא‑רשמי שמפרסם gov.il, אוסרות בתקנה 1 העברת מידע ממאגר בישראל אל מחוץ למדינה, אלא אם דין המדינה המקבלת מבטיח רמת הגנה שאינה נופלת מזו של הדין הישראלי. תקנה 2 מונה חלופות, ובהן העברה לתאגיד בשליטת בעל המאגר שהתחייב להגן על הפרטיות, והעברה למי שקשור בהסכם עם בעל המאגר לעמוד בתנאי החזקה והשימוש החלים על מאגר בישראל. תקנה 3 מוסיפה חובה עצמאית: התחייבות בכתב של מקבל המידע לנקוט אמצעים נאותים, ולא להעבירו לאדם אחר.

ולעניין בנק חוץ, 364 §170.2 מוסיפה דרישה מפורשת: שמירה בכל עת, במערכות המידע המקומיות בסניפיו בישראל, של נתונים מלאים על בעלי החשבונות, מיופי הכוח וזכויות החתימה, ושל כל היתרות העדכניות.

הערה על הפניות בין הוראות: 362 מפנה בגוף הטקסט להוראות 359A, 361, 363, 350 ו‑355; 364 מפנה ל‑362 ול‑366. אלו הפניות צולבות, וכך הן מובאות כאן.

6 · רשת מנותקת — מה באמת משתנה

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

תשע ההשלכות המעשיות:

1. אין CDN. גופנים, ערכות אייקונים וספריות JS חייבים להיות מוטמעים בחבילה.
2. אין טלמטריה — ומה שכן נדרש הופך לייצוא ידני שאפשר לבדוק. ה‑ Service Connection Tool של Microsoft הוא הדוגמה: התוכנה אורזת נתוני שימוש לקובץ, אדם מעביר אותו למחשב מקוון, משם יורדים העדכונים וחוזרים פנימה — ויש דגל -export שמאפשר לקרוא בדיוק מה עומד לצאת מהבניין לפני שהוא יוצא.
3. אין phone-home לרישוי. זו שאלה שיש לשאול כל ספק במפורש ולקבל עליה תשובה בכתב, כי היא נבדקת רק כשהקו כבר מנותק.
4. אספקת עדכוני תוכן היא משימה אנושית מתוזמנת, עם checksum. הקצב היחיד שמישהו פרסם שווה לאמץ כברירת מחדל: Tenable ממליצה על עדכוני feed לפחות פעם בחודש, ועל שדרוגי מוצר לפחות פעם בשנה — רבעוני עדיף.
5. מופע אחד לכל רשת מנותקת. Tenable מנסחת זאת כדרישה ארכיטקטונית, והיא מכלילה: אין «אחד מרכזי» שרואה שתי רשתות שלא רואות זו את זו.
6. אין זהות בענן. אין ספק זהות מארח ואין SSO אליו — AD/LDAP או חשבונות מקומיים, ומסלול מתועד לשניהם.
7. תעודות. אין נתיב אימות אל רשות אישורים ציבורית, אין OCSP/CRL ואין ACME. נדרשת רשות אישורים פנימית — ואדם שזוכר את תאריך החידוש.
8. זמן. מקור NTP פנימי. אימות תעודות ואימות אסימונים תלויים בו שניהם. (ניסיון תפעולי, לא דרישת תקן.)
9. הזנת החולשות היא התחייבות תפעולית מתמשכת, לא אירוע חד‑פעמי. מישהו נושא קובץ פנימה, כל חודש, לתמיד. האדם הזה הוא שורה בתוכנית כוח האדם, ואם הוא לא מופיע שם — התהליך לא תוכנן, הוא רק תואר.

7 · מה נשבר ראשון כשהמצאי גדל

דיסק, ואחריו IOPS. מיקרוסופט אומרת זאת במפורש בדף הסיזינג שלה, ומוסיפה שברגע שדרישות ה‑CPU והזיכרון הבסיסיות מסופקות, תת‑מערכת האחסון היא בעלת ההשפעה הגדולה ביותר על ביצועי האתר. הטבלאות של Tenable מראות את אותה תמונה מכיוון אחר: מ‑2,500 ל‑100,000 כתובות פעילות, ה‑CPU והזיכרון גדלים פי שישה בקירוב — והדיסק גדל פי 35.

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

ולכן השאלה אף פעם אינה «כמה שרתים יש לכם». היא כמה × כמה היסטוריה × כמה סוגי רשומה — ושניים מתוך שלושת הגורמים האלה הם החלטות מדיניות, לא עובדות על המצאי. אחד מהם, תקופת השמירה, מוסדר ב‑364 §61.7.3 שדורש «פרק זמן הולם» ואינו נוקב במספר. כלומר הארגון חייב להחליט, ולכתוב.

כמה נתונים נכס מייצר — החשבון, לא המספר

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

מקור	החישוב	התוצאה
Tenable SC, סריקות בסיס, 10,000 IP ל‑90 יום = 450GB	450GB ÷ 10,000	≈45MB לנכס ל‑90 יום
Tenable SC, בתוספת ביקורת תצורה, 10,000 IP ל‑90 יום = 900GB	900GB ÷ 10,000	≈90MB לנכס ל‑90 יום
ConfigMgr, 25,000 לקוחות = 350GB	350GB ÷ 25,000	≈14MB ללקוח
ConfigMgr, 150,000 לקוחות = 1,600GB	1,600GB ÷ 150,000	≈10.7MB ללקוח

8 · שתים‑עשרה שאלות לספק, לפני שחותמים

שמונה הראשונות הן של NIST SP 800‑40r4 §3.7, בתרגום. הן נכתבו כדי להישאל את כל מי שמוכר תוכנה — כולל אותנו.

1. האם תשחררו עדכונים לתוכנה הזו כדי לטפל בחולשות?
2. כמה טלאים, עדכונים ושדרוגים אתם צופים לשחרר בשנה? תוך כמה זמן בממוצע אתם צופים לטפל בחולשה ולשחרר טלאי? האם אתם מאגדים טלאים יחד או שכל אחד נפרד? באיזו תדירות אתם צופים לשחרר עדכוני חירום?
3. לכמה שנים אתם מחויבים לתקן חולשות בתוכנה?
4. האם תשחררו עדכונים בלוח זמנים קבוע, לפי הצורך, או בשניהם?
5. האם יש לכם תוכנית לגילוי חולשות ולתגובה לאירועים עבור התוכנה? עד כמה אתם שקופים בתקשורת בנושאי אבטחה מול לקוחות?
6. כשחולשה בתוכנה שלכם מתפרסמת ועדיין אין טלאי — מה אתם ממליצים ללקוחות לעשות כדי להגן על הנכסים שלהם?
7. כשהתוכנה מתעדכנת, עד כמה זה משבש? האם נדרשת הפעלה מחדש של התוכנה, אתחול של הנכס?
8. איך אתם בודקים טלאים לפני שחרור? באיזו תדירות לקוחות חווים תקלות משמעותיות מטלאי שלכם? האם אתם מספקים יכולת החזרה לאחור?

וארבע שנגזרות מהמקורות שלמעלה:

9. מה אין בפריסה המקומית שיש במנוהלת, ולהפך? רשימה פריטית, לא הצהרה. יש תקדים: ServiceNow פרסמה בדיוק כזו.
10. איך מגיע עדכון תוכן לרשת מנותקת, באיזה קצב, מי נושא את הקובץ ואיך מאמתים אותו? תשובה טובה כוללת שם של פורמט ושל checksum, לא «אנחנו תומכים ב‑air gap».
11. איך נראית תוכנית היציאה, ומי משלם על הבדיקה שלה? EBA §§107–108 דורשות שהיא תהיה מתומחרת ונבדקת; 362 §31(ה) דורשת סקירה אחת לשלוש שנים.
12. האם החוזה מחייב אתכם למסור קבצי Log ממערכותיכם לפי דרישה? 364 §61.7.5 מבקש מהבנק לשקול בדיוק את החיוב הזה — כלומר זה סעיף שמצופה להימצא בחוזה.

מה הדף הזה לא טוען

זה החלק ששווה להעביר גם למי שכותב מכרזים.

מותר: «מתוכנן סביב הדרישות של סעיף 61.4» · «מייצר את נתיב הביקורת שסעיף 98 מדבר עליו» · «תומך בראיות שלכם».

אסור, וגם לא נכתב כאן: «עומד בהוראה 364» · «מוסמך» · «ISO compliant» · «ITIL aligned». אף ספק אינו הופך תאגיד בנקאי לעומד בהוראה, הפיקוח על הבנקים אינו מאשר מוצרים, וכל ניסוח שנשמע כמו הסמכה נתפס תוך דקה על ידי צוות הציות של הקונה.

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

איפה זה נגמר

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

• הוראה 364 — הדרישות שאנחנו בונים מולן
• מוכנות להוראה 364 — מדריך לצוותי תשתיות
• פלייבוק לתיאום חלונות תחזוקה