מעבר ל-HSM ולסיסמאות ראשיות: המדריך לאנשי IT ו-CISO לטכנולוגיית Multi-Party Computation (MPC)

קיים גם באנגלית.

במשך עשרות שנים, עולם אבטחת התשתיות התבסס על אקסיומה ברורה: אם יש לנו מפתח הצפנה רגיש, סיסמת שורש או פעולה בעלת השפעה קריטית, עלינו לנעול אותם בכספת החזקה ביותר שניתן למצוא. התוצאה הייתה הסתמכות כבדה על חומרות ייעודיות מסוג Hardware Security Module (HSM), תהליכי אימות דו-שלבי מחמירים, ומדיניות ניהול הרשאות (RBAC) נוקשה.

אולם ככל שארכיטקטורות המחשוב נעות לעבר סביבות Multi-Cloud, עבודה היברידית ועיבוד נתונים משותף, מנהלי IT ו-CISOs מגלים פרדוקס בלתי נמנע:

1. עלויות חומרה ונעילת ספק: רכישת HSM פיזי, רישוי מורכב וסנכרון בין עננים שונים מייצרים עלויות תקציביות כבדות (CapEx) וסרבול תפעולי קיצוני.
2. האשליה של נקודת כשל בודדת (Single Point of Failure): גם מאחורי ההגנות המחמירות ביותר, בסופו של יום קיים מפתח הצפנה ראשי (Master Key) או סיסמת CISO/Root שמישהו, מתישהו, עלול לחשוף — בין אם בטעות אנוש, בהתקפת הנדסה חברתית, או עקב עובד סורר.
3. הגנה מוגבלת על נתונים בפעולה (Data-in-Use): הצפנה קלאסית מגנה היטב על נתונים במנוחה (At Rest) או בתנועה (In Transit), אך כדי לבצע חישוב, ניתוח או חתימה — המידע או המפתח חייבים להתפענח בזיכרון המחשב (RAM).

טכנולוגיה בשלה שהחלה את דרכה במחקר האקדמי וכיום מיושמת בפרודקשן בארגונים המובילים בעולם מציעה פרדיגמה שונה לחלוטין: Multi-Party Computation (MPC).

---

מה זה בעצם MPC? (הסבר פרקטי לאנשי תשתיות)

חישוב מרובה משתתפים בטוח (Multi-Party Computation) הוא תחום בקריפטוגרפיה המאפשר למספר שרתים או ישויות נפרדות לחשב במשותף פונקציה על גבי הנתונים שלהם, מבלי שאף צד ייחשף לקלט של הצד האחר, ומבלי שיידרש צד שלישי מהימן (Trusted Third Party).

במקום העיקרון המסורתי של "נעילת המפתח השלם במקום אחד", MPC מבוסס על קריפטוגרפיית סף (Threshold Cryptography) וחלוקת סודות (Secret Sharing):

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

[שרת AWS (רסיס A)] <---+ 
                       |---> [פרוטוקול חישוב MPC] ---> [חתימה מאושרת / תוצאה]
[שרת Azure (רסיס B)] <--+        (ללא שחזור המפתח השלם!)
                       |
[שרת On-Prem (רסיס C)] <-+

---

3 תרחישים שבהם איש IT צריך לשקול MPC

1. חיפוש חלופה גמישה וחסכונית ל-HSM בענן (Virtual Cloud HSM)

מנהלי תשתיות רבים מוצאים את עצמם לכודים מול עלויות אחזקה ורישוי של התקני חומרה פיזיים. בנוסף, בסביבת Multi-Cloud קשה מאוד לגרום ל-HSM של ספק ענן אחד (כגון AWS CloudHSM) לתקשר באופן מאובטח ומהיר עם אפליקציות הרצות ב-Google Cloud או ב-Azure.

המענה של MPC:

מערכת ניהול מפתחות מבוזרת (Distributed KMS) מבוססת תוכנה. ניתן לפזר את רסיסי המפתח בין אזורי ענן שונים וספקים שונים. האבטחה אינה נשענת על מעטפת ברזל פיזית בארון שרתים בודד, אלא על העובדה המתמטית שתוקף נדרש לפרוץ בו-זמנית למספר סביבות ענן מבודדות לחלוטין כדי להשיג את המפתח.

2. אבטחת ה-Root: מה קורה אם סיסמת ה-CISO או חשבון ה-Admin נפרצים?

אחת החרדות המשמעותיות של כל מנהל אבטחת מידע היא תרחיש "פריצת ה-Master Key": עובד מפתח שסרח, תקיפת פישינג מתוחכמת על מנהל הרשת, או גניבת Session Token של משתמש על.

המענה של MPC:

ביטול נקודת הכשל הבודדת באמצעות מודל סף (Threshold Scheme, למשל 2 מתוך 3 או 3 מתוך 5):

• לאף אדם, מנהל מערכת או שרת יחיד אין יכולת לבצע פעולת הצפנה או חתימה קריטית באופן חד-צדדי.
• אפילו אם תוקף משיג שליטה מלאה על מחשבו של ה-CISO או גונב את רסיס המפתח שלו, אין לרסיס זה שום ערך מתמטי בפני עצמו (Zero-Knowledge leakage).
• כדי לאשר פעולה, המערכת מחייבת השתתפות חישובית של שרתים ומשתמשים נוספים לפי מדיניות הארגון.

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

צוותי Data ומוצר מעוניינים לעיתים קרובות להצליב נתונים מול שותפים עסקיים (למשל: בנקים המבקשים לזהות דפוסי הונאה משותפים, או מערכות בריאות המצליבות נתוני חולים לצורך מחקר), אך דרישות רגולציה קפדניות (GDPR, HIPAA, חוק הגנת הפרטיות) מונעות העברת קובצי Raw Data.

המענה של MPC:

שימוש באלגוריתמי הצלבה מאובטחת כגון Private Set Intersection (PSI). הארגונים יכולים לקבל את התשובה המשותפת בלבד (למשל: כמות הלקוחות המשותפים או זיהוי פעילות חריגה), מבלי שאף צד ייחשף למאגר הנתונים של עמיתו.

---

השוואה טכנית: HSM מסורתי מול Cloud KMS מול MPC מבוזר

---

שאלות שארכיטקטי IT שואלים על MPC

האם תקשורת הרשת לא מייצרת השהיה (Latency) גבוהה מדי?

בעבר, פרוטוקולי MPC היו כבדים מבחינת תעבורת רשת. כיום, ספריות מתקדמות ואלגוריתמי חתימה מודרניים (כגון MPC-based ECDSA ו-EdDSA) מייצרים חתימות במילי-שניות בודדות. עבור רוב המערכות הארגוניות וניהול המפתחות, ה-Latency זניח לחלוטין בהשוואה ליתרונות השרידות והאבטחה.

מה ההבדל בין MPC לבין הצפנה הומומורפית (FHE)?

בעוד ש-Fully Homomorphic Encryption (FHE) מאפשרת לבצע חישובים על נתונים מוצפנים בתוך שרת יחיד אך סובלת מעומס חישובי כבד ביותר (פי אלפים מחישוב רגיל), MPC מפזר את המשימה בין מספר שרתים. העומס ב-MPC הוא בעיקרו תקשורתי ולא חישובי, מה שהופך אותו לפרקטי ומוכן לפרודקשן כבר היום.

האם רסיסי המפתח (Shares) נחשבים מידע אישי לפי תקנות פרטיות?

מבחינה מתמטית ומשפטית, רסיס מפתח או נתון שעבר Secret Sharing בצורה תקינה אינו מכיל מידע (Entropy מלאה) ולבד אינו מאפשר שחזור של המקור. לכן הוא אינו מהווה PII ואינו מסכן את הארגון במקרה של דליפת רסיס בודד.

---

סיכום וצעדים מעשיים למנהלי תשתיות

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

1. מפו את נקודות הכשל הבודדות (SPOF): היכן שמורים מפתחות ה-Master של הארגון? האם פריצה לחשבון יחיד יכולה להשבית את הפעילות?
2. בדקו את עלויות ה-HSM: האם חידוש הרישוי והחומרה של קופסאות האבטחה שלכם תואם את האסטרטגיה המודרנית של ריבוי עננים?
3. התנסו ב-Virtual KMS מבוסס MPC: בחנו הטמעת פיילוט לניהול מפתחות מבוזר בסביבת Staging כדי לחוות את פשטות הניהול מול רמת האבטחה הגבוהה.