אבטחה ויושרה

אבטחה ויושרה של העסקאות הפיננסיות שלנו

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

1. שרתי הליבה הבנקאית

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

• שרתי עיבוד עסקאות: מבצעים בזמן אמת אישור תשלומים, בדיקות הונאה וסילוקים (למשל SWIFT, SEPA).
• שרתי ניהול חשבונות: מטפלים באירועי מחזור החיים של החשבון (פתיחה/סגירה), בחישובי ריבית ובניטור נזילות.
• שרתי ציות רגולטורי: אוטומציה של בדיקות AML (למניעת הלבנת הון), מסלולי ביקורת ודיווח (למשל IFRS, GDPR).

2. שרתי ספר חשבונות

אחראי לשמירת רישומים פיננסיים בלתי ניתנים לשינוי:

• שרתי ספר ראשי: עוקבים אחר הנהלת חשבונות כפולה בין החשבונות, ומבטיחים ציות לתקני חשבונאות כגון IFRS.
• שרתי טכנולוגיית ספר חשבונות מבוזר (DLT): מערכות מבוססות בלוקצ'יין לתשלומים חוצי גבולות, לאימות KYC וליומני עסקאות חסינים מפני שינוי.

3. שרתי תקשורת חיצונית
מאפשרים אינטראקציות מאובטחות עם גורמים חיצוניים:

• שרתי EBICS: מנהלים את תקן התקשורת הבנקאית האלקטרונית באינטרנט (Electronic Banking Internet Communication Standard) לתשלומי SEPA, הנמצא בשימוש נרחב בגרמניה, בצרפת ובשווייץ.
• שרתי Host-to-Host‏ (H2H): חיבורי SFTP/FTPS ישירים לעסקאות תאגידיות בהיקף גבוה (למשל עיבוד שכר מרוכז).
• שרתי שער API: מספקים ממשקי RESTful ליזום תשלומים בזמן אמת ולאיחוד חשבונות (מאובטחים באמצעות OAuth2/mTLS).
• שרתי ממשק Swift: מחברים את הבנק לרשת Swift לצורך העברת הודעות בין-בנקאיות (SCORE היא קבוצת משתמשים סגורה של Swift לגישה של תאגידים, ואינה סוג של שרת).

4. שרתי מסדי נתונים
מאגרים מרכזיים של נתונים פיננסיים מובנים:

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

5. שרתי אבטחה ותשתית
הבטחת שלמות המערכות והציות הרגולטורי:

• שרתי מודול אבטחת חומרה (HSM): מגנים על מפתחות קריפטוגרפיים עבור חתימות דיגיטליות והצפנת SSL/TLS.
• שרתי חומת אש/VPN: אכיפת הפרדת רשת וגישה מרחוק מאובטחת לעובדים.
• שרתי התאוששות מאסון: מארחים מערכות גיבוי להמשכיות עסקית בעת הפסקות שירות.

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

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

• שיטה משולבת: וירטואליזציה (VMware, KVM) או קונטיינריזציה (Docker/Kubernetes)
• דוגמה: אירוח של מספר פורטלי בנקאות (קמעונאי, תאגידי, נייד) באשכול Hypervisor עם איזון עומסים.

2. שרתי מסדי נתונים

• שיטה משולבת: מסדי נתונים רב-דיירים בענן (AWS RDS, Azure SQL)
• מסדי נתונים של מערכות בנקאיות ליבתיות מבוססי Oracle/MS SQL יכולים להתקיים לצד מערכות אנליטיקה מבוססות PostgreSQL/MongoDB בהתקנות ענן היברידיות.

3. שערי תקשורת חיצוניים

• שיטת שילוב: שערי API מאוחדים (Apigee, MuleSoft)
• שירותי EBICS, SWIFT ו-SFTP יכולים לפעול על תשתית משותפת עם מיקרו-שירותים ייעודיים לכל פרוטוקול.

4. שרתי התאוששות מאסון

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

5. שרתי תווך

• שיטת שילוב: Enterprise Service Bus (ESB)
• ניתוב תשלומים, בדיקות ציות ושירותי המרת מטבע מאוחדים על גבי IBM Integration Bus/SAP PI.

שרתים שיש להשאירם מבודדים
1. שרתי עיבוד עסקאות מרכזיים

• נימוק: הפרדה (פיזית או באמצעות פילוח קפדני) מצמצמת את היקף הבקרות של PCI DSS ו-SOC 2
• דוגמה: מערכות IBM zSystems המריצות מוניטורי עסקאות CICS אינן יכולות לחלוק חומרה עם עומסי עבודה אחרים.

2. שרתי מודול אבטחת חומרה (HSM)

• הסיבה: תקן FIPS 140-2/140-3 ברמה 3 מחייב חומרה ייעודית עמידה בפני חבלה
• יישום: מודולי HSM של Thales/Gemalto המטפלים בחתימות דיגיטליות ובמפתחות הצפנה.

3. מערכות ספר חשבונות בזמן אמת

• סיבה: הנהלת חשבונות כפולה מחייבת אטומיות
• דוגמה: שרתי ספר חשבונות של Oracle Financial Services עם אחסון NVMe המחובר ישירות.

4. שרתי דיווח רגולטורי

• הנימוק: יש להגן על יומני הביקורת מפני שינוי ולשמור אותם לתקופות הנדרשות על פי GDPR ודיני AML; ההפרדה מקלה על הוכחת הדבר
• תצורה: מופעי SQL Server מבודדים לדוחות MiFID II/FATCA.

5. מערכות הרשאה של כספומטים ו-POS

• סיבה: התחייבות זמינות של 99.999% ודרישות הפרדת רשת
• ארכיטקטורה: מערכות IBM Power עם רשתות אחסון Fibre Channel כפולות.

מגבלות טכניות:

• מערכות בנקאות ליבה בנפח גבוה דורשות חיבורי רשת ייעודיים ברוחב פס גבוה
• PCI DSS מחייב להפוך מספרי כרטיס שמורים (PAN) לבלתי קריאים ולהפריד את סביבת נתוני בעלי הכרטיסים
• תוכנית אבטחת הלקוחות של Swift (CSP) מחייבת כי תשתית Swift תמוקם באזור מאובטח ומוגן

איחדנו בהצלחה 80% מהשרתים הלא קריטיים (אינטרנט/יישומים/תווך), תוך שמירה על בידוד מלא של מערכות הליבה, ה-HSM וספר החשבונות.

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

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

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

2. בידוד רשתות

• ארכיטקטורת VPC: יש להפעיל את שרתי ספר החשבונות ברשתות משנה פרטיות ללא גישה מרשת האינטרנט הציבורית.
• קבוצות אבטחה: הגבלת תעבורה נכנסת ליציאות מסוימות (כגון PostgreSQL/Aurora) מטווחי כתובות IP שאושרו מראש.
• נקודות קצה של VPC: שימוש ב-AWS PrivateLink לתקשורת מאובטחת בין שרתי ספר החשבונות לבין שירותים כגון S3/KMS ללא חשיפת נתונים לרשת הציבורית.

3. הצפנה

• במצב מנוחה: מפתחות המנוהלים על ידי AWS KMS מצפינים את נתוני ספר החשבונות ב-Amazon Aurora, עם החלפת מפתחות אוטומטית.
• בתנועה: אכיפת TLS 1.3 בכל התקשורת בין לקוח לשרת ובין שירותים.
• הצפנה בצד הלקוח: הצפנה מוקדמת של שדות רגישים (למשל יתרות חשבון) לפני האחסון באמצעות AWS Encryption SDK.

4. בקרת גישה

• תפקידי IAM: הקצאת הרשאות פרטניות (למשל תפקידים המאפשרים הוספה בלבד) כדי למנוע מחיקת נתונים מקרית או זדונית.
• אישורי גישה זמניים: יש להשתמש ב-AWS STS לגישה מוגבלת בזמן בעת עבודות תחזוקה.
• אכיפת MFA: יש לדרוש אסימוני חומרה (YubiKey) לחשבונות root/מנהל.

5. ניטור וביקורת

• התראות בזמן אמת: יש להגדיר את AWS CloudWatch כך שיפיק התראות על דפוסי עסקאות חריגים (למשל העברות הגבוהות מ-1 מיליון אירו).
• יומני פעילות: מעקב אחר כל שינוי בספר החשבונות באמצעות AWS CloudTrail המשולב בכלי SIEM.
• ביקורות אוטומטיות: הרצת כללי AWS Config שבועיים לאימות מצב ההצפנה ומדיניות הרשת.

6. ציות וממשל תאגידי

• הפרדה מבוססת אזורים: הפרדה בין סביבות ספר חשבונות DEV/TEST/PROD באמצעות AWS Organizations.
• דוחות אוטומטיים: הפקת דוחות ציות ל-PCI DSS/GDPR באמצעות AWS Audit Manager.
• ביקורות של צד שלישי: יש לתזמן מבחני חדירה שנתיים בעזרת שותפים שאושרו על ידי AWS.

7. התאוששות מאסון

• שכפול בין אזורים: שמירת עותקים מוצפנים של פנקס הרישומים באזורי AWS בפרנקפורט ובשטוקהולם.
• שחזור לנקודת זמן: הפעלת גיבויים רציפים המאפשרת שחזור נתונים לכל שנייה בתוך תקופת השמירה (עד 35 ימים).
• גיבויים מנותקי רשת (Air-gapped): שמירת תצלומי מצב רבעוניים של פנקס החשבונות ב-AWS Backup Vault עם תקופת שמירה של 7 שנים.

כדי למנוע התפשטות של רישומים זדוניים לשרתי התאוששות מאסון (DR), בנקים מיישמים אסטרטגיות אבטחה רב-שכבתיות המבודדות את הגיבויים, אוכפות בקרות גישה מחמירות ומאמתות את שלמות הנתונים. להלן פירוט טכני של אמצעי המפתח:
1. גיבויים בלתי ניתנים לשינוי בתצורות Write-Once-Read-Many (WORM)

• מטרה: מניעת שינוי או הצפנה של נתוני גיבוי בידי תוכנות כופר.

יישום: יש להשתמש ב-AWS S3 Object Lock או ב-Azure Blob Immutable Storage כדי למנוע מחיקה או שינוי במשך תקופת שמירה מוגדרת. יש להחיל גיבוב קריפטוגרפי (SHA-256) על קבצי הגיבוי; כל שינוי בלתי מורשה פוסל את הגיבוב ומפעיל התראות.
2. שכפול מנותק מהרשת ובלתי מקוון

• בידוד רשת: יש לאחסן את שרתי ה-DR ב-VPC/VLAN נפרד ללא גישה נכנסת מהאינטרנט. יש להשתמש בשכפול חד-כיווני (ראשי ← DR) באמצעות כלים כגון AWS Storage Gateway או Azure Site Recovery, תוך חסימת סנכרון בכיוון ההפוך.
• בידוד פיזי (Air-Gapping): למערכות קריטיות יש לשמור גיבויי סרט או אחסון לא מקוון המתחברים רק בחלונות שכפול מתוזמנים.

3. בקרות גישה במודל אפס אמון (Zero-Trust)

• אימות זהות: אכיפת MFA בכל ממשקי הניהול של התאוששות מאסון (DR) (למשל AWS SSO, Azure AD Conditional Access). הקצאת תפקידי IAM בהרשאות מינימליות הנדרשות (למשל `s3:GetObject` בלבד).
• אבטחת רשת: יש להגביל את תעבורת השכפול למנהרות IPsec VPN או ל-AWS Direct Connect/Azure ExpressRoute. יש להטמיע מערכות לזיהוי חדירות (IDS) כגון Snort או Suricata לניטור ערוצי השכפול.

4. אימות שלמות הנתונים

• בדיקות לפני שכפול: סריקת נתוני המקור לאיתור תוכנות זדוניות באמצעות כלים כגון ClamAV או CrowdStrike Falcon לפני השכפול. השוואת סכומי ביקורת לפני ההעברה ואחריה כדי לאתר שינוי בלתי מורשה.
• ביקורות לאחר שכפול: יש להשתמש ב-AWS Config או ב-Azure Policy כדי לאכוף מדיניות הצפנה וגישה בשרתי ההתאוששות מאסון. יש לתזמן בדיקות שלמות יומיות באמצעות סקריפטים (למשל אימות `sha256sum`).

5. סביבות מופרדות לוגית

6. בדיקות אוטומטיות של מעבר לגיבוי

• התקפות מדומות: שימוש בכלים כגון Chaos Monkey כדי לדמות הדבקות בתוכנת כופר ולאמת את עמידותם של שרתי התאוששות מאסון (DR). מדידת יעדי זמן ההתאוששות (RTO) ויעדי נקודת ההתאוששות (RPO) במהלך התרגילים.
• ניתוח פורנזי: שמירת 90 ימים של VPC Flow Logs ואירועי CloudTrail לצורך איתור חריגות בשכפול.

יישום גיבויים בלתי ניתנים לשינוי הוא קריטי להגנה על נתונים מפני כופרה (ransomware), מחיקות בשוגג והפרות ציות. בהתבסס על תקני התעשייה וכלים כגון AWS, Veeam ו-Azure, להלן שיטות העבודה המומלצות:
1. אכיפת אי-שינוי ברמת שכבת האחסון

• יש להשתמש בתצורות WORM (כתיבה חד-פעמית, קריאה מרובה) באמצעות אחסון אובייקטים עם S3 Object Lock (AWS), Azure Immutable Blob Storage או Veeam Hardened Repositories.
• הפעילו נעילות שמירה כדי למנוע מחיקה או שינוי בטרם עת, גם על ידי מנהלי מערכת.

2. אימוץ אסטרטגיית גיבוי 3-2-1-1

• 3 עותקים של הנתונים (עותק ראשי + שני גיבויים)
• 2 סוגי אמצעי אחסון (למשל דיסק + ענן)
• עותק אחד מחוץ לאתר (מבודד גיאוגרפית)
• עותק בלתי ניתן לשינוי אחד (מנותק מהרשת או התומך ב-WORM).

3. הטמעת בקרות גישה מחמירות

• בקרת גישה מבוססת תפקידים (RBAC): הגבלת הרשאות באמצעות תפקידי IAM (למשל מדיניות גישה לכספת גיבוי של AWS Backup).
• אימות רב-גורמי (MFA): יש לאכוף עבור ממשקי ניהול גיבויים (למשל Azure AD Conditional Access).
• בידוד רשת: אחסנו גיבויים ברשתות משנה פרטיות/VPC ללא גישה לאינטרנט הציבורי.

4. הצפנת נתונים מקצה לקצה

• במנוחה: שימוש במפתחות AES-256 או במפתחות המנוהלים על ידי KMS (AWS, Azure).
• בתנועה: TLS 1.3 לערוצי שכפול.
• הצפנה בצד הלקוח: הצפנה מוקדמת של שדות רגישים לפני הגיבוי (לדוגמה, הצפנת AES-256 של Veeam עם מפתחות המנוהלים על ידי המשתמש).

5. אוטומציה של שמירה ואימות

• מדיניות שימור: הגדרת RPO/RTO ואוטומציה של כללי מחזור חיים (למשל, שימור של 7 שנים ב-AWS Backup Vault).
• אימות סכום ביקורת (Checksum): בדיקת שלמות לפני שכפול ואחריו (למשל, גיבוב SHA-256).
• ביקורות סדירות: יש להשתמש בכלים כגון AWS Config או Veeam SureBackup כדי לבדוק שחזורים.

6. הטמעת שכבות אבטחה בסביבות היברידיות

7. הבטחת ציות ואי-הפיכות

• נעלו את הגדרות אי-השינוי לאחר הבדיקות (למשל, מצב "Enabled and locked" של Azure).
• עמידה בדרישות הרגולציה: התאמה ל-GDPR, ל-HIPAA או ל-SOX באמצעות כלים כגון AWS Audit Manager.
• ביקורות צד שלישי: יש לתזמן מבדקי חדירה שנתיים (למשל באמצעות שותפים מאושרים של AWS).

דוגמה לזרימת עבודה עם AWS ו-Veeam
1. גיבוי ראשי: Veeam Backup & Replication אל דלי S3 עם Object Lock.
2. שכפול: AWS DataSync לאזור משני (פרנקפורט → שטוקהולם).
3. אימות: בדיקה יומית של יומני CloudTrail + תרגילי שחזור רבעוניים.
4. שימור: תקופה בלתי ניתנת לשינוי של 90 יום עם הצפנת KMS.

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