ארכיטקטורת אבטחה למערכות פיננסיות
בלוג טכני למפתחים, ארכיטקטים וצוותי אבטחה שעובדים עם תשתיות מסחר ונתונים פיננסיים. אנחנו מפרסמים ניתוחים מעמירים על קוד, פרוטוקולים וארכיטקטורה — לא ייעוץ השקעות, לא המלצות מסחר, ולא שירותי ייעוץ בתשלום. כל התוכן פתוח לקריאה ללא הרשמה.
קריאת המאמריםהאתר מופעל על ידי TechCorp · בני ברק, ישראל · מדיניות פרטיות
מה קורה כשהמסחר עובר ל-microservices
במשך רוב שנות האלפיים, חדרי המסחר של הבנקים הגדולים נשענו על מערכות מונוליתיות שנבנו בשנות התשעים. קוד COBOL ו-Java מוקדם שרץ על שרתים פיזיים בחדרי שרתים מאובטחים בלונדון, ניו יורק וטוקיו. המערכות האלה עבדו. הן היו איטיות, מסורבלות ויקרות לתחזוקה — אבל הן עבדו. הבעיה החלה כשהרגולטורים דרשו שקיפות גבוהה יותר, הלקוחות ציפו לזמני תגובה של מילישניות, והיקף הנתונים גדל פי מאה בתוך חמש שנים.
התוצאה: כמעט כל מוסד פיננסי גדול עבר או נמצא בעיצומו של מעבר לארכיטקטורת מיקרו-שירותים. בבורסה לניירות ערך בתל אביב, למשל, מערכת המסחר הוחלפה ב-2019 בפלטפורמה מבוססת טכנולוגיית Nasdaq שמטפלת באלפי הודעות בשנייה. זה נשמע כמו שיפור, וזה באמת שיפר את הביצועים. אבל זה גם פתח חלון תקיפה חדש לגמרי.
במערכת מונוליטית, כל הקוד רץ בתוך תהליך אחד. התקשורת בין רכיבים היא קריאות פונקציה בזיכרון. במערכת מיקרו-שירותים, כל שירות הוא תהליך נפרד — לפעמים על שרת אחר, לפעמים באזור גיאוגרפי אחר. התקשורת ביניהם עוברת ברשת. וברשת, כמו שכל מהנדס אבטחה יודע, הדברים מתחילים להשתבש.
ראיתי את זה קורה ביותר מפרויקט אחד: צוות הפיתוח בונה שירותים מצוינים, צוות ה-DevOps פורס אותם בקפידה, ואף אחד לא חושב על כך ששירות ה-authentication מדבר עם שירות ה-order management דרך HTTP רגיל במקום mTLS. או שהלוגים של שירות התשלומים כוללים, בטעות, מספרי כרטיסי אשראי מלאים כי מישהו שכח לסנן שדה ב-log formatter. ב-2023, חברת פינטק ישראלית שנסחרת בנאסד"ק גילתה פרצת אבטחה שמקורה בדיוק בתקשורת לא מוצפנת בין שני מיקרו-שירותים פנימיים.
מה שעוד השתנה זה קצב השינוי עצמו. לפני עשור, עדכון גרסה של מערכת מסחר היה אירוע שתוכנן חודשים קדימה. היום, עם CI/CD ופריסות canary, קוד חדש מגיע לייצור כמה פעמים ביום. זה מצוין מבחינת מהירות פיתוח. אבל כל פריסה כזו היא נקודת סיכון פוטנציאלית — שינוי בקונפיגורציה של firewall, עדכון תלות שכוללת פגיעות חדשה, או container image שלא עבר סריקה.
יש גם את עניין הספקים החיצוניים. חברה שנסחרת בבורסה בתל אביב עשויה להשתמש ב-30 עד 50 ספריות קוד פתוח, 5 עד 8 שירותי SaaS חיצוניים, ו-3 או 4 ספקי ענן שונים. כל אחד מהם הוא וקטור תקיפה פוטננציאלי. מתקפת SolarWinds מ-2020 הוכיחה ששרשרת האספקה של תוכנה היא בדיוק המקום שבו תוקפים מתוחכמים מחפשים פרצות.
איך אנחנו ניגשים לניתוח
נתחיל תמיד מהארכיטקטורה, לא מהסימפטומים. לפני שבוחנים חולשות ספציפיות, צריך להבין את המפה: מי מדבר עם מי, איפה מסתיים הגבול של כל שירות, ואיך הנתונים זורמים ביניהם. אני זוכר פרויקט שבו צוות האבטחה היה משוכנע שהבעיה נמצאת ב-API Gateway. אחרי שמיפינו את הארכיטקטורה המלאה, התברר שהחולשה האמיתית הייתה בתקשורת בין שני שירותים פנימיים שאף אחד לא חשב לבדוק.
השלב השני הוא ניתוח זרימת הנתונים. במערכות פיננסיות, כל ביט של מידע שעובר ברשת צריך להיות מסווג: מה רגיש, מה מצריך הצפנה בתנועה, ומה אסור לרשום בלוגים בכלל. אני משתמש ב-diagrams של data flow, לא בצ'קליסטים של compliance. ההבדל הוא כמו ההבדל בין להבין איך מנוע עובד לבין לדעת שיש לו טסט בתוקף.
השלב האחרון: תרגום של ממצאים טכניים לשפה עסקית. CTO לא צריך לשמוע שיש "פגיעות ברמת high" — הוא צריך לדעת מה הסיכון העסקי, מה העלות של תיקון לעומת העלות של אי-תיקון, ומה סדר העדיפויות. בעיניי, דוח אבטחה שלא מובן למי שקורא אותו הוא דוח שלא שווה את הזמן שהושקע בכתיבתו.
מה אנחנו עושים כאן
ניתוח ארכיטקטורת אבטחה
פרסום ניתוחים טכניים מעמיקים על ארכיטקטורות אבטחה של מערכות פיננסיות — מרמת הפרוטוקול ועד לרמת התשתית. כל מאמר מבוסס על סטנדרטים פתוחים של NIST ו-OWASP, עם דוגמאות קוד ודיאגרמות ארכיטקטורה.
סקירות תשתיות מסחר
בחינה טכנית של תשתיות בורסות ומערכות clearing — איך בנויות מערכות ה-matching, מה ההבדלים בין פרוטוקולי FIX ל-Streaming, ואיך מנהלים latency של מיקרו-שניות. הסקירות מבוססות על תיעוד ציבורי וניתוח הנדסי.
מדריכי קריפטוגרפיה שימושית
מדריכים מעשיים על הטמעת הצפנה, ניהול מפתחות, HSM, ופרוטוקולי TLS — עם דגש על מערכות שעומדות בתקנים כמו PCI DSS ורגולציה בנקאית. הקוד במדריכים מבוסס על ספריות open source מתוחזקות.
מה הבלוג הזה לא כולל
- לא ייעוץ השקעות, לא ניתוח מניות, לא המלצות מסחר — לא במישרין ולא בעקיפין
- לא שירותי pentest, vulnerability assessment, או SOC מנוהל
- לא תוכן שיווקי עבור ספקי אבטחה או חברות פינטק
- לא פרשנות משפטית — לזה צריך עורך דין, לא בלוג טכני
מה חדש
עדכון אחרון: מאי 2026 — עדכון המדריך על Zero Trust עם הפניות מעודכנות ל-NIST SP 800-207.
חדש: מאמר על HSM ואיך מנהלים מפתחות הצפנה בתשתיות פיננסיות.
תשתית: האתר עבר שכתוב מלא במרץ 2026 עם תמיכה משופרת במובייל.
מצאתם טעות טכנית במאמר? שלחו לי מייל ואעדכן. אני מעדיפה תיקונים ישירים על פני ביקורת כללית.
מאמרים מומלצים
ארכיטקטורת Zero Trust במערכות פיננסיות: מדריך למימוש מ-mTLS ועד Service Mesh
למה "אמון אפס" זה לא סיסמה שיווקית אלא גישה הנדסית שמתחילה ב-mTLS ומסתיימת ב-RBAC גרנולרי — עם דוגמאות קוד של Istio ו-Linkerd.
Event-Driven Architecture בבורסות: Kafka, Flink וצנרת הנתונים של עולם המסחר
איך בורסות מודרניות מעבדות מיליוני הודעות בשנייה — מהפרוטוקול ועד ה-FPGA.
HSM וניהול מפתחות: ה-Root of Trust שתשתיות פיננסיות בנויות עליו
הבדלים בין CloudHSM ל-HSM פיזי, FIPS 140-3, ואיך בוחרים פתרון נכון.
שאלות שנשאלות לא מעט
האם zero trust באמת שונה ממה שעשו קודם, או שזה בעיקך rebranding?
זו שאלה הוגנת. ברמת העיקרון, zero trust מבוסס על רעיונות שקיימים לפחות מאז 2004 — כש-Jericho Forum דיברו על "de-perimeterization". ההבדל הוא בשלות הכלים: mTLS, service mesh כמו Istio, ו-policy engines כמו OPA הפכו את הגישה לפרקטית. לפני חמש שנים, ליישם zero trust דרש פרויקט של שנה. היום, עם הכלים הנכונים, אפשר להתחיל בשבועיים.
איזה בורסה משתמשת בטכנולוגיה מתקדמת יותר — Eurex או CME?
השוואה מעניינת. Eurex (חלק מ-Deutsche Börse) רצה על פלטפורמת T7 שמבוססת Java ו-C++ עם latency של מיקרו-שניות בודדות. CME משתמשת ב-iLink 3.0 שמבוסס על FIX/FAST עם FPGA acceleration ל-matching engine. שתיהן מתקדמות, אבל בגישות שונות — Eurex שמה דגש על גמישות ו-protocol richness, CME על raw speed. תלוי מה אתה מודד.
אנחנו סטארטאפ של 5 אנשים. הגיוני בכלל לחשוב על zero trust?
הגיוני, אבל בפרופורציה. עם 5 אנשים, אפשר להתחיל עם WireGuard ל-mTLS, Let's Encrypt להנפקת תעודות, ו-Vault לניהול סודות. אל תנסו להטמיע Istio על קוברנטיס אם יש לכם 3 שירותים. הזהירות היחידה: zero trust מוסיף overhead תפעולי. אם אין לכם מישהו שמבין PKI, זה יהיה נטל במקום יתרון.
מה ההבדל בין HSM פיזי לבין CloudHSM מבחינת אבטחה בפועל?
HSM פיזי (כמו Thales Luna) יושב בחדר השרתים שלכם, מוגן בחומרה נגד tampering, ונותן לכם שליטה מלאה. CloudHSM (כמו AWS CloudHSM) הוא HSM ייעודי בענן — מבודד, מוצפן, אבל בתשתית של מישהו אחר. מבחינת FIPS 140-3, שניהם יכולים לעמוד ברמה 3. ההבדל העיקרי הוא ביצועים בשפיצים ורמת השליטה בקונפיגורציה.
כמה פעמים אתם מעדכנים את התוכן בבלוג?
מאמר חדש יוצא בערך פעמיים בחודש. עדכונים למאמרים קיימים — כשיש שינוי מהותי בתקן, כלי חדש, או חולשה שנחשפת. אני לא מאמינה בלפרסם תוכן רק בשביל ה-SEO. אם אין מה לחדש, אני לא מפרסמת.
אפשר להשתמש במאמרים שלכם כחומר הדרכה בצוות?
בהחלט. כל התוכן בבלוג פתוח לקריאה ולשיתוף. אם אתם רוצים להשתמש במאמר כבסיס להרצאה פנימית או workshop, אשמח לשמוע על זה — שלחו לי מייל. רק תנו קרדיט וקישור למקור.