פיתוח ארנק לא-משמור מקצה לקצה מאפס

מדוע ארנק לא־משמור מאבד מפתחות וגישה

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

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

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

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

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

מה משתנה בעבודה עם נכסים לאחר ההטמעה

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

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

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

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

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

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

ארנק לא־משמור מול ארנק משמור והיברידי

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

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

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

כיצד אנו מובילים את הפרויקט: ממודל איומים ועד מסירה

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

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

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

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

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

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

מקרה בוחן: ארנק לשירות עם זרימת תשלומים

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

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

מדדים לפני ואחרי

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

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

במה בידוד חומרתי של מפתחות שונה מתוכנה?

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

אבל כל תוכנה זדונית עם גישה לזיכרון התהליך מקבלת גם את המפתח וגם את היכולת לחתום — אי אפשר טכנית להפריד בין שני האירועים האלה.

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

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

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

ספקות טכניים: מפתחות, גיבויים, ביקורת

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

האם אפשר להחליף מאוחר יותר את תבנית החתימה?

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

כיצד נבדקת תקינות הקוד?

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

מי אחראי לעדכונים לאחר המסירה?

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

נדון במשימה: מה לשלוח להערכה מדויקת

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

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

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