הרגולטורים הציבו רף גבוה יותר בנושאי הבטחת זהות (Identity Assurance), יכולת ביקורת (Auditability) וממשל צד שלישי (Third-party Governance). תקן PCI DSS 4.0 מהדק את הציפיות לגבי רישום לוגים (Logging), הצפנה ואימות – כאשר סעיפים רבים שהוגדרו כ"בעלי תאריך עתידי" (Future-dated) ניתנים כעת לאכיפה מלאה החל מ-31 במרץ 2025. דירקטיבת NIS2 מביאה עמה חובות רוחביות לניהול סיכונים ודיווח מהיר על תקריות ברחבי האיחוד האירופי. חוק DORA הופך את החוסן התפעולי (Operational Resilience) לדרישה חוקית עבור גופים פיננסיים החל מ-17 בינואר 2025.

בכל שלושת המקרים, הנושא המעשי הוא זהה: להוכיח מי נגע במה, לשלוט כיצד נתונים רגישים נעים, ולהציג את עבודתכם באמצעות ראיות בלתי ניתנות לשינוי (Immutable Evidence). זהו בדיוק המקום שבו פלטפורמת העברת קבצים מנוהלת ומאובטחת (Secure Managed File Transfer – MFT) מודרנית מוכיחה את ערכה.

כדי לשמור על גישה טקטית, כל סעיף להלן עונה על ארבע שאלות:

1. מה הכלל דורש, 2) כיצד פלטפורמת MFT עוזרת, 3) הראיות שמבקרים (Auditors) מצפים לראות, 4) מלכודות שיש להימנע מהן.

לאורך הדרך, נשלב באופן טבעי בקרות סמוכות (למשל: בקרת גישה מבוססת תפקיד (RBAC), נהלי עבודה מומלצים לניהול מפתחות, החלפת נתונים באפס אמון (Zero Trust), יומני ביקורת (Audit Logs) בלתי ניתנים לשינוי, דרישות דיווח על תקריות, ווי חיוג (Hooks) למניעת דליפת נתונים (DLP), ושרשרת משמורת (Chain of Custody) לקבצים) – מכיוון שהמבקרים ישאלו עליהם, בין אם ראשי התיבות הם PCI, NIS2 או DORA.

PCI DSS 4.0: מ"מאובטח מספיק" לתזרימי נתונים מאובטחים שניתן להוכיחם

מה הכלל דורש תקן PCI DSS 4.0 (וגרסת הרוויזיה המוגבלת 4.0.1) מבהיר את ציפיות ההצפנה במעבר (In Transit) ובמנוחה (At Rest), מרחיב את בקרות האימות, ומעלה את הרמה של רישום לוגים/ניטור כך שתוכלו לשחזר מי ניגש לנתוני מחזיקי כרטיס ומתי. רוב הסעיפים החדשים שהוגדרו כ"עתידיים" הפכו לחובה ב-31 במרץ 2025; גרסה v4.0.1 עצמה לא הוסיפה או הסירה דרישות – אלא רק הבהרות ותבניות.

מה מבקרים מחפשים (בהקשר של העברה):

• העברת קבצים מוצפנת (TLS 1.2+ / חבילות צופן חזקות) מקצה לקצה.
• ניהול מפתחות חזק (מגובה HSM/KMS, רוטציה, הפרדת רשויות).
• בקרת גישה פרטנית (RBAC, MFA) על מאגרים ותזרימים.
• רישום לוגים מקיף: מי שלח/קיבל אילו קבצים, מתי, ומאיפה.
• אחסון המעיד על זיוף (Tamper-evident) עבור לוגים ותוצרים (אי-השתנות, שימור).
• זיהוי שינויים בקונפיגורציה ובתזרימים; התרעה ותגובה.
• יכולת להדגים זכות גישה מינימלית (Least Privilege) וסקירות הרשאות תקופתיות.

כיצד MFT עוזר (בקרה ← דרישה)

• הצפנה מבוססת מדיניות במנוחה ובמעבר ← מספקת את סעיפי ההצפנה של PCI עבור נתוני מחזיקי כרטיס (CHD) ונתוני אימות רגישים (SAD) המאוחסנים ומועברים (עם משמורת מפתחות שניתנת להגנה).
• RBAC + MFA לבני אדם ולחשבונות שירות ← מיישר קו עם דרישות זהות חזקות יותר ותאימות להעברת קבצים מאובטחת.
• יומני ביקורת בלתי ניתנים לשינוי עם ייצוא ל-SIEM ← תומך בחקירה ובמנדט "שחזור האירועים" של PCI.
• ווי DLP וסריקת נוזקות בכניסה/יציאה ← מונעים חשיפה מקרית והעלאות זדוניות.
• אישורי זרימת עבודה (Workflow) והפרדת רשויות ← הפרדה נקייה בין מבקשים, מאשרים ומפעילים.
• שימור אוטומטי ומחיקה ניתנת להגנה (Defensible deletion) ← תואם לחלונות זמן של שמירת ראיות ומצמצם את היקף הבדיקה (Scope).

ראיות שיש להכין

• דיאגרמת זרימת נתונים של עמוד אחד עבור העברות הקשורות למחזיקי כרטיס (פנימי/B2B).
• צילומי מסך + תמציות של הגדרות הצפנה, מדיניות צפנים (Cipher Policies) ורוטציות KMS.
• שבילי ביקורת (Audit Trails) לדוגמה המציגים משתמש, קובץ, זמן, כתובת IP של המקור, תוצאה (הצלחה/דחייה).
• מטריצת זכות גישה מינימלית (תפקידים ← הרשאות) עם תאריך סקירה אחרון.
• חיפושי SIEM שמוצאים ומתריעים על דפוסי העברה חשודים.

מלכודות

• הצפנת הצינור אך לא המטען (Payload) – כלומר, היעדר הצפנה ברמת האובייקט.
• מתן אפשרות לחשבונות שירות "זמניים" להמשיך להתקיים ללא סקירות RBAC.
• לוגים שהם אומנם בחיפוש (Searchable) אך אינם מעידים על זיוף או אינם נשמרים למשך זמן מספק.

ניצחון מהיר: התייחסו ל-MFT שלכם כאל מערכת רשומות (System of Record) לתנועת נתונים של מחזיקי כרטיס – הדקו את ה-TLS, אכפו RBAC/MFA, דחפו לוגים ל-SIEM, ונעלו את מדיניות השימור. ארבעת המהלכים הללו פותרים את רוב שאלות העברת הקבצים ב-PCI DSS 4.0 כבר בשער הפתיחה.

NIS2: מ"מיטב המאמצים" להיגיינת סייבר ודיווח חובה

מה הכלל דורש NIS2 מרחיב את ההיקף (יותר מגזרים; ישויות "חיוניות" ו"חשובות") ומעגן בחוק אמצעים לניהול סיכונים פלוס דיווח מהיר על תקריות: אזהרה מוקדמת תוך 24 שעות, הודעה על תקרית תוך 72 שעות (24 שעות עבור ספקי שירותי אמון), עם דוחות מעקב ודוחות סופיים בקצב מוגדר.

כיצד MFT עוזר (בקרה ← חובה)

• החלפת נתונים באפס אמון (Zero Trust): פרסום נקודות קצה של העברות כאפליקציות (לא כרשתות), חסימת גישה באמצעות זהות + יציבת מכשיר (Device Posture).
• יומני ביקורת מרכזיים ובלתי ניתנים לשינוי: הדגמה מי ניגש לנתונים מפוקחים, מתי וכיצד; ייצוא לרגולטורים במידת הצורך.
• התרעה אוטומטית ואינטגרציה עם SIEM: סימון חריגות (קפיצות בנפח, צדדים נגדיים חריגים, הפרות מדיניות) לתמיכה באזהרה מוקדמת.
• ניהול סיכוני צד שלישי: אכיפת מדיניות עבור ספקים/שותפים (זהויות, MFA, בקרת RBAC חוזית, גידור גיאוגרפי/זמן).
• סיווג נתונים עם ניתוב מבוסס מדיניות: תזרימים רגישים מפעילים בקרות חזקות יותר (אישור, רמת הצפנה, DLP).

ראיות שיש להכין

• סט מדיניות המתאר אימות, הרשאה והצפנה עבור החלפת נתונים תחת NIS2.
• זרימת עבודה לדיווח על תקריות (מי מרכז את חבילות ה-24/72 שעות; מאיפה נשלפות הראיות).
• נוהל הפעלה (Runbook) לאנומליות בהעברה ממופה לנהלי SOC ופתיחת קריאות (Ticketing).
• רשימת תיוג לקליטת ספק (הוכחת זהות, MFA, החלפת מפתחות, פרוטוקולים מותרים).

מלכודות

• התייחסות לקבצים מצורפים לדוא"ל כ"טובים מספיק" להעברת קבצים מפוקחת.
• אישור מכשירי שותפים לא מנוהלים ללא בדיקות יציבה (Posture Checks).
• שמירת הלוגים ב-MFT אך אי-הזרמתם ל-SIEM (תזדקקו לקורלציה במהלך ספרינט 72 השעות).

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

DORA: חוסן תפעולי הוא כעת חוק עבור גופים פיננסיים באיחוד האירופי

מה הכלל דורש DORA (תקנה (EU) 2022/2554) חלה החל מ-17 בינואר 2025 ומחייבת גופים פיננסיים להוכיח ניהול סיכוני תקשוב (ICT), דיווח על תקריות, בדיקות חוסן (כולל TLPT), ופיקוח הדוק על ספקי תקשוב צד שלישי. זו אינה המלצה; זוהי רגולציה אכיפה עם שיניים.

כיצד MFT עוזר (בקרה ← סעיף בחוק)

• קטלוג שירותים ושרשרת משמורת לקבצים ← תומך במרשמי נכסים ומיפוי "פונקציות קריטיות"; לכל העברה בסיכון גבוה יש בעלים, מדיניות ולוג.
• הצפנה חזקה + מחזור חיי מפתח ← עומד בציפיות סודיות/שלמות; מפתחות חיים ב-KMS/HSM עם רוטציה והפרדת רשויות.
• ממשל צד שלישי ← מדיניות מתוקננת עבור צדדים נגדיים חיצוניים; בקרות חוזיות אוכפות דרישות דיווח על תקריות, RBAC, והעברת קבצים מוצפנת.
• ווי (Hooks) בדיקות חוסן ← סימולציה של השבתות שותפים, אובדן חבילות מידע (Packet Loss), או פקיעת תוקף תעודות; הוכחת ירידה הדרגתית בתפקוד (Graceful Degradation) ולוגיקה של ניסיון חוזר/חזרה לאחור (Retry/Rollback).
• אינטגרציית SOAR/SIEM ← התרעות בזמן אמת וחבילות ראיות עבור תקריות חייבות דיווח (מי/מה/מתי, היקף, מיטיגציה) – קריטי תחת משטרי תאימות DORA.

ראיות שיש להכין

• מרשם של תזרימי קבצים קריטיים (תהליך עסקי, מחלקת נתונים, צדדים נגדיים, בקרות).
• פלטים של ספרי הפעלה (Playbook) מבדיקות (כשל והתאוששות – Failover, חזרה לאחור – Rollback, ניסיונות חוזרים, תרגילי רוטציית תעודות).
• אישורי צד שלישי (MFA, מצב הצפנה, אנשי קשר לתקריות ו-SLAs).
• חבילות ביקורת: לוגים בלתי ניתנים לשינוי + סיכומים עבור מדגם של העברות בסיכון גבוה.

מלכודות

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

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

השוואת בקרות (דף עזר – Cheat Sheet)

הצפנה במעבר ובמנוחה מספקת את דרישות PCI DSS 4.0 להגנה על CHD/SAD; מהווה בסיס לאמצעי הסיכון של NIS2; מצופה תחת אבטחת ה-ICT של DORA.

RBAC + MFA (כולל זהויות שאינן אנושיות) מצמצם את היקף ה-PCI ותומך בזכות גישה מינימלית; מיישר קו עם אמצעי "המילה האחרונה" (State-of-the-art) של NIS2; מצופה עבור גופי DORA המנהלים תזרימי נתונים רגישים.

יומני ביקורת בלתי ניתנים לשינוי ← SIEM PCI: שחזור אירועים במהלך הערכות; NIS2: תמיכה בדוחות 24/72 שעות; DORA: הזנת ניהול תקריות ופלטים של בדיקות חוסן.

DLP, AV/CDR בכניסה/יציאה מונע מעבר תוכן זדוני ודליפת נתונים בכל שלושת המשטרים.

אכיפת מדיניות צד שלישי בקרות בחוזה (MFA, הצפנה, SLA לדיווח) + אכיפה טכנית (פרוטוקולים, צפנים, גידור גיאוגרפי) מספקות את ציפיות הפיקוח של NIS2/DORA.

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

מפת דרכים ליישום (90 יום)

ימים 0-30 – ביסוס ועבודת תשתית (Baseline & block-and-tackle)

• בצעו אינוונטר (מלאי) של כל תזרימי הנתונים המפוקחים (מחזיקי כרטיס, אישי, תפעול פיננסי).
• אכפו TLS 1.2+ בכל מקום; דרשו RBAC + MFA לגישה אנושית וגישת שירות.
• הפעילו יומני ביקורת בלתי ניתנים לשינוי והזרימו אותם ל-SIEM; הגדירו שימור.
• אפשרו DLP וסריקת נוזקות בכל נקודות ההחלפה הנכנסות/יוצאות.

ימים 31-60 – ממשל וצדדים שלישיים

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

ימים 61-90 – חוסן ודיווח

• תרגלו רוטציית תעודות וכשל והתאוששות (Failover) של נקודות קצה של שותפים; תעדו את התוצאות.
• חברו "התרעות רגולטוריות" לתוך ה-SOAR כדי לפתוח כרטיסים אוטומטית לדיווח 24/72 שעות.
• הריצו תרגיל שולחני (Tabletop) המדמה תקרית חייבת דיווח שמקורה בתזרים קבצים.

מה להראות למבקרים – מהר

• דיאגרמה אחת לכל תזרים מפוקח (מקור ← מדיניות ← יעד)
• שלושה צילומי מסך: מדיניות צפנים, RBAC/MFA, שימור/אי-השתנות
• שני תמצירי לוגים: העברה מוצלחת עם מטא-דאטה מלא; ניסיון שנדחה עם סיבה
• כרטיס SOAR אחד: התרעה שהופעלה עם חותמות זמן ופעולות שננקטו

חבילת "1-3-2-1" זו עונה על 80% משאלות העברת הקבצים בסקירות PCI/NIS2/DORA.

מילה אחרונה

אתם יכולים להקשיח (Harden) כל נקודת קצה ועדיין להיכשל בהערכה אם אינכם יכולים להוכיח כיצד קבצים רגישים חוצים את האחוזה שלכם. פלטפורמת MFT מודרנית – המיושמת כהעברת קבצים מנוהלת ומאובטחת ולא כ"SFTP מהולל" – הופכת הצפנה, RBAC, רישום לוגים וממשל שותפים לבקרות שניתן לחזור עליהן (Repeatable Controls) עם ראיות מוכנות לביקורת. זהו הנתיב הקצר ביותר לעמידה בחובות העברת קבצים של PCI DSS 4.0, ייעול החלפת נתונים ב-NIS2, ועמידה בתאימות DORA מבלי להאט את העסק.