פיתוח ארנק ווב: היכן נשברת האבטחה
ארנק ווב פועל בסביבה העוינת ביותר שאפשר: המפתח הפרטי שוכן לצד הדפדפן, תוספים של צד שלישי והאינטרנט הפתוח. בעיות האבטחה של ארנק ווב מצטמצמות כמעט תמיד לשלוש נקודות כשל — שמירת מפתחות בזיכרון השירות, חתימת עסקאות בצד הלקוח והיעדר בידוד של צומת החתימה. כל אחת מהן מספיקה בנפרד כדי לאבד כספי משתמשים ואת האמון במוצר.
התרחיש היקר ביותר — אחסון במשמורת: מפתח או צירוף מילים מנמוני BIP-39 יושבים במסד הנתונים של השירות ונותרים בדאמפים של זיכרון, בלוגים, בגיבויים ובסביבות בדיקה. דליפת מפתחות פרטיים היא בלתי הפיכה — אי אפשר להנפיק מחדש כתובות או לבטל עסקאות.
לכן ארכיטקטורת אחסון המפתחות מתוכננת כך שהסוד לא יתקיים בשום מקום בצורה גלויה: טקסט מוצפן תחת סיסמת המשתמש, פיצול הסוד בין צמתים, חתימה בתוך מודול שלא מוציא את המפתח החוצה.
הנקודה השנייה — חתימת עסקאות בצד הלקוח. תוסף זדוני או סקריפט מוזרק מחליף את כתובת הנמען בין התצוגה לחתימה, והמשתמש מאשר משהו שלא ראה על המסך. זה נסגר באמצעות השוואת פרמטרים בשכבה מהימנה, בדיקת הכתובת מול רשימה לבנה ואיסור מפורש על חתימה עיוורת.
הנקודה השלישית — היעדר בידוד של צומת החתימה. כאשר החתימה ושכבת האפליקציה חיים באותו תהליך עם הרשאות משותפות, פגיעה בחלק הוובי פותחת מיד גישה למפתחות.
את החתימה מוציאים לשירות נפרד או למודול חומרה בלי יציאה ישירה לרשת, וההחלטה מתקבלת לפי מדיניות: למי מותר, כמה פעולות ביממה, מה דורש אישור ידני.
בהמשך נפרט כיצד הנקודות האלה נסגרות באמצעות סכמה, הרשאות גישה וכללי תפעול.
אפקט ההטמעה: מהירות שחרורים וסיכונים שהוסרו
כל עוד יש רשת אחת, הארכיטקטורה כמעט לא משפיעה על הקצב. ברגע שיש שלוש-ארבע רשתות, כל אינטגרציה חדשה גוררת שינויים בליבה, בנייה נפרדת ורגרסיה מלאה — השחרור נדחה לסוף המחזור, והסיכוי לפגוע בקוד של אחר גדל עם כל שינוי.
לאחר העיבוד מחדש, תיאור הרשת מועבר לקונפיגורציה הצהרתית: הליבה נשארת ללא שינוי, וחיבור רשת חדשה מצטמצם למערכת פרמטרים ובדיקות.
זה משנה שתי מדדים בבת אחת. זמן ההשקה של רשת חדשה מתקצר משבועות לכמה ימים, ושיעור הפעולות הידניות בחיבור יורד: המהנדס כבר לא מתקן קוד, אלא ממלא תיאור ומריץ בדיקות אוטומטיות לפי תרחיש קליטה טיפוסי.
הפחתת סיכון הפגיעה נשענת לא על הבטחות, אלא על גבול האמון. המפתחות לא יוצאים מהמתחם המוגן, חתימת העסקה מתבצעת בתהליך מבודד, ולחלק הלקוח אין כלל גישה לסודות. מחלקה שלמה של כשלים — דליפת מפתח דרך הממשק או היומנים — מפסיקה להתקיים באופן מובנה, ולא באמצעות מסננים מעל הסכמה הקודמת.
זמן ההתאוששות לאחר תקלה הופך לצפוי. המצב והקונפיגורציות מנוהלים בגרסאות, והחזרה לגרסה תקינה קודמת מתבצעת בלי מיגרציית נתונים, כך שהשירות חוזר לפעול בדקות ולא בשעות.
בנפרד יורד העומס על התמיכה: פניות טיפוסיות — עסקה תקועה, רשת לא נכונה, יתרה שלא מוצגת — נסגרות באבחון אוטומטי עוד לפני שהן מגיעות למהנדס תורן.
מודלים לאחסון מפתחות: השוואה ומגבלות
מודל אחסון המפתחות קובע מי מנהל את הכספים ומה יקרה אם אחד הצדדים נפגע. עבור ארנק ווב זה לא בחירה בין «בטוח או לא», אלא מערכת של פשרות בין נוחות הכניסה, עלות החתימה והיקף האחריות של השירות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מודל אחסון במשמורת | השירות חותם על עסקאות ומשחזר גישה, ולמשתמש נדרשת רק כניסה | פגיעה או תקלה בשירות מאפסת את היתרות של כל הלקוחות בבת אחת |
| ארנק שאינו במשמורת | המפתח נשמר אצל המשתמש, והשירות לא נוגע בכספים | אובדן מפתח הוא בלתי הפיך, ופישינג ותוספים זדוניים פוגעים ישירות בבעלים |
| ריבוי חתימות | בכספים מנהלים כמה צדדים לפי כלל m מתוך n | החתימה יקרה יותר, ויש לתאם מראש את הרכב המשתתפים ואת רוטציית המפתחות |
| פיצול מפתח בין צדדים | יש צורך להסיר נקודת אמון יחידה: חלקים מוחזקים אצל מחזיקים שונים | הרכבת החלקים בעת החתימה היא סיכון נפרד, ונחוץ נוהל שחזור |
| מודול חתימה חומרתי | המפתח לא יוצא מהמודול, והחתימה מתבצעת בתוך המתחם | חומרה ותחזוקה שלה, תקרה לפעולות בהיקף גדול, עדכונים מורכבים יותר |
בפועל משלבים סכמות: ארנק שאינו במשמורת עם מודול חתימה חומרתי בדרגת FIPS 140 סוגר גם את האחסון וגם את החתימה, וריבוי חתימות מעל פיצול מפתח מסיר את התלות במחזיק אחד.
אנחנו מקבעים את המודל הנבחר בארכיטקטורה לפני שורת הקוד הראשונה — אחרת החלפת הסכמה בהמשך מחייבת שכתוב של כל שכבת החתימה.
פיתוח ארנק ווב: שלבי העבודה ההנדסית
השלבים מתבצעים לפי הסדר: סכמת החתימה קובעת אילו סביבות ומפתחות לבודד, ומהן נגזרת מערכת בדיקות התרחישים. להלן מסלול טיפוסי לארנק ווב שבו המפתחות הפרטיים לא יוצאים ממכשיר המשתמש או ממודול אחסון ייעודי.
- ביקורת תשתית הארנק. מפרקים את המתחם הנוכחי: היכן יושבים המפתחות, למי יש גישה אליהם, כיצד מוקצות תפקידים, מה נכנס ליומן. התוצאה — מפת אמון ורשימת מקומות שבהם אפשר ליירט חתימה או להחליף עסקה.
- תכנון סכמת החתימה והתפקידים. בוחרים מודל: מפתח במכשיר המשתמש, סכמת סף עם כמה מחזיקים או מודול חתימה ייעודי בצד השירות. קובעים היכן נדרש אישור שני והיכן הפעולה מתבצעת אוטומטית.
- הגדרת סביבות. מפרידים בין פיתוח, רשת בדיקה ומתחם ייצור כך שמפתחות בדיקה לא יגיעו לסביבת הייצור. קונפיגורציה, הרשאות וסודות נמצאים במקום אחד ומנוהלים בגרסאות.
- בדיקות תרחישים ועומס. מריצים שחזור גישה, החלפת מכשיר, עסקה שנדחתה, חתימות במקביל מכמה לשוניות. בנפרד — התנהגות בזמן כשל של צומת רשת ובעיכוב תגובה.
- שחרור הדרגתי. פותחים גישה לחלק מהמשתמשים ועוקבים אחרי שיעור החתימות המוצלחות ואחרי כשלים בצד הרשת. מגבלות על סכום העסקה ותדירות החתימה פעילות מהיום הראשון.
- מסירה והדרכת הצוות. פורסים את הבנייה והשחרור בצד שלכם, מוסרים תיעוד על סכמת החתימה והתפקידים וכן נוהל תגובה לאירועים. עוברים עם המהנדסים על רוטציית מפתחות.
ערכת מסירה: קונפיגורציות, סכמות, נהלים
מסירת ארנק היא לא ארכיון של קוד מקור, אלא מתחם עבודה שצוות הלקוח מקים ומתחזק בלעדינו. את הערכה מרכיבים כך שפריסת סביבה חדשה תימדד בשעות, והתגובה הראשונה לאירוע לא תדרוש שיחה עם המחבר.
- קונפיגורציות סביבות — פרמטרים של רשת, מגבלות עמלות, רשימת נכסים וכתובות צמתים עבור מתחם בדיקה, קדם-ייצור וייצור. העתק של הסביבה מוקם באמצעות החלפת ערכים, בלי שינויי קוד.
- סכמות של זרימות חתימה — היכן נוצר המפתח, היכן נשמר החלק הסגור, כיצד נחתמת העסקה ואילו בדיקות קיימות בכניסה וביציאה. מהסכמה רואים שחומר המפתח לא יוצא מהמתחם המוגן.
- מדיניות גישה ותפקידים — מי צופה ביתרות, מי יוזם משיכה, מי מאשר פעולה. הרשאות ניתנות לפי המינימום הנדרש לתפקיד, ולא «ליתר ביטחון» — עובד חדש לא מקבל יכולות מיותרות.
- נוהל תגובה לאירועים — צעדים בעת חשד לפגיעה במפתח, זינוק בפעולות לא אופייניות או כשל של שירות חיצוני: מי עוצר פעולות, כיצד מתעדים החלטה ובמה מאשרים חזרה למצב תקין.
- הנחיות לתמיכה — ניתוח פניות טיפוסיות, מה לבדוק ביומני האירועים, אילו שגיאות המשתמש פותר בעצמו ומתי הפנייה עוברת למהנדס תורן.
- סדר רוטציית מפתחות ושחזור מגיבויים — עם תדירות, תחומי אחריות ובדיקה מחייבת בסביבת בדיקה לפני יישום בייצור.
מקרה בוחן: איך הסרנו מחלקת כשלים והאצנו שחרורים
שירות קריפטו קמעונאי עם ארנק שאינו במשמורת Aurora Wallet выпускал обновления אחת לשבועיים: בנייה, השוואה ידנית של כתובות חוזים, חתימת בניות ופרסום לייצור התבצעו לפי רשימת בדיקה בת 42 סעיפים.
בחתימה מקבילה מכמה מכשירים מצב הסשן התפצל, וחלק מהעסקאות נתקעו בתור לאישור — טיפול במקרה כזה לקח לתמיכה עד יממה.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| פעולות ידניות בשחרור | 42 שלבים לפי רשימת בדיקה | 4 שלבים ניתנים לבדיקה |
| זמן שחרור עדכון | כשני ימים | 40 דקות |
| מסלולים מכוסים בבדיקות אוטומטיות | 35% | 88% |
| תקיעות בחתימה מקבילה | 3-5% מהפעולות | 0 בתקופת הניטור |
| חזרה לגרסה קודמת | כשעתיים | דקות |
מה שינו בפועל: את החתימה הוציאו למודול מבודד עם בנייה חד-משמעית של נתוני החתימה, ואת הפעולות העבירו ליומן עם הגנה מפני חזרות — בקשה חוזרת עם אותו מזהה לא יוצרת עסקה שנייה.
קונפיגורציית הרשת וכתובות החוזים תוארו באופן הצהרתי, ולכן הסביבה מוקמת מהמאגר בלי שינויים ידניים, והרצה ברשת בדיקה הפכה לשלב חובה לפני הייצור.
מחלקת הכשלים שהוסרה — אי-סנכרון מצב בחתימה בו-זמנית — כבר לא משוחזרת לא ברשת הבדיקה ולא בייצור. השחרור הפסיק להיות אירוע עם תורנות לילה: הצוות מפרסם שינויים לפי המוכנות ומחזיר אותם בדקות אם המדדים חורגים מהצפוי.
מה עושים אם הארנק כבר פועל ועובד?
ארנק פעיל מועבר לסכמת אחסון חדשה בלי לעצור את השירות: לצידו מוקם מתחם מקביל, ולא מחליפים את מתחם הייצור. המשתמשים ממשיכים להיכנס, לקבל כתובות ולחתום על עסקאות — בצד שלהם לא משתנים לא הממשק, לא צירוף המילים לגיבוי ולא רשימת הכתובות. ההעברה מתבצעת ברקע, במנות, כל עוד המתחם הישן נשאר מקור האמת.
המפתחות הפרטיים של המשתמשים לא נוצרים מחדש — אחרת היו משתנים הכתובות והיתרות. משתנה שכבת האחסון והחתימה: הסודות מוצפנים מחדש תחת מפתח שורש חדש, וכל פריט שהועבר נבדק בכך שהמפתח המפוענח מפיק את אותה כתובת ציבורית. אם הבדיקה לא עוברת — הפריט חוזר לסכמה הישנה ומטופל בנפרד, ושאר המנה ממשיכה הלאה.
רוטציית מפתחות מתבצעת בשלבים: מפתחות הצפנה חדשים לאחסון ולחתימת השירות מוכנסים לפעולה, והישנים, במהלך חלון ההעברה, נשארים זמינים לקריאה בלבד. התאימות לארנק הנוכחי נשמרת בזכות קבלת שני הפורמטים — בניות לקוח שיצאו קודם ממשיכות לחתום ולא דורשות עדכון ביום המעבר.
את המעבר עושים לפי קבוצות משתמשים, ולא בבת אחת: המתחם החדש עובד תחילה על תעבורת צל, שבה תוצאות החתימה בשני המצבים מושוות בייט-בייט, ופער עוצר את הפריסה עד לבדיקה. החזרה לאחור — מעבר הפוך בצד השירות, שבו המפתחות בסכמה הקודמת נשארים תקפים, ולכן שום פעולת משתמש לא הולכת לאיבוד. לאחר השוואה ותקופת ניטור, המתחם הישן מוצא משירות.
שאלות טכניות: אבטחה, אינטגרציות, ביקורת
החששות של הלקוח מצטמצמות לארבעה נושאים: היכן יושבים המפתחות, מה קורה בכשל רשת, כיצד נבדקת האינטגרציה ומה נכלל בדוח לפני השחרור. להלן תשובות קצרות לכל אחד.
היכן נשמרים המפתחות הפרטיים ומה יקרה אם המכשיר נפגע?
המפתח לא יוצא מהחלק הלקוח: החתימה נבנית מקומית, ולשרת נשלחת רק העסקה החתומה. לדרישות מוגברות מחברים מודול חתימה חיצוני או ארנק חומרתי — ואז גישה לדפדפן אינה מספיקה כדי לחתום על העברה.
כיצד נבדקת האינטגרציה עם רשתות ומה קורה כשצומת לא זמינה?
כל רשת מטופלת על ידי כמה צמתים בלתי תלויים עם מעבר בעת כשל, וסטטוס העסקה נבדק מול כמה מקורות ולא מול תגובה אחת. לפני השחרור מריצים עיכובי אישור ושליחה חוזרת — זה מקור נפוץ ליתרות «נעלמות».
מה נכלל בבדיקת הקוד והתשתית לפני שחרור?
ניתוח קוד בידי מומחים חיצוניים, בדיקת תלויות, בדיקות שחזור גישה ותרחישי חזרה לאחור, סקירת הרשאות לשרתים ולסודות. בנפרד מוודאים שהיומנים אינם מכילים מפתחות וצירופי מילים מנמוניים — דליפה טיפוסית של רישום לא זהיר.
למי יש גישה לתשתית וכיצד יוצאים עדכונים?
גישה ניתנת לפי המינימום הנדרש, עם אימות דו-גורמי ויומן פעולות; משיכת כספים דורשת אישור של כמה חותמים. עדכונים יוצאים לרשת בדיקה, לאחר מכן לקבוצה מוגבלת, ואז לכולם — החזרה לאחור לוקחת דקות.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם נוסחים כלליים, אנחנו צריכים הקשר טכני מינימלי על הארנק. ככל שהנתונים המדויקים יותר, כך יש פחות הנחות בתמחור ובלוחות הזמנים. להלן מה שכדאי לשלוח מיד ומה נבהיר בשיחה הראשונה.
- רשתות ונכסים נתמכים: מטבעות מקוריים, טוקנים, האם נדרשים קריאת יתרות והיסטוריית פעולות לפי כתובות או רק חתימה ושליחה.
- מודל מפתחות: היכן נשמר המפתח הסגור — אצל המשתמש במכשיר או בצד השירות, האם נדרשים ארנקים חומרתיים ושחזור גישה.
- דרישות אבטחה: אימות רב-גורמי, מגבלות על פעולות, רישום ביומן, בדיקת כתובת הנמען, כללי שמירת נתונים אישיים.
- תרחישי משתמש: יצירה וייבוא ארנק, שליחה, המרה פנימית, חיבור לשירותים חיצוניים באמצעות חתימת הודעות.
- אינטגרציות חיצוניות: צמתי רשת משלכם או של צד שלישי, ספקי שערים, שירותי תשלום, מערכת הרשאה ותשתית קיימת.
- מגבלות: תוסף דפדפן, יישום ווב או ווב נייד, רשימת דפדפנים נתמכים, דרישות זמינות.
- מצב נוכחי: אבות טיפוס, עיצוב, נכסי קוד קיימים, ביקורת אבטחה שנעשתה בעבר.
בהמשך נחזור עם הערכה לפי שלבים, הרכב צוות בהתאם להיקף שלכם ותוכנית ברורה: מהנדס ראשי בתחום הבלוקצ'יין, פיתוח צד לקוח וצד שרת, מומחה אבטחה, בודק. פורמט שיתוף הפעולה — איטרציות עם הצגת תוצאה בסוף כל אחת, גישה למאגר הקוד ולמשימות, ושינוי היקף מתועד בכתב.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית עבודה.