אינטגרציה עם Fireblocks: אחסון מאובטח ופיננסים מבוזרים

אינטגרציה עם Fireblocks: היכן נשבר אחסון המפתחות

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

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

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

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

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

מה משתנה בעבודה עם מפתחות ועסקאות

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

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

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

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

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

מצבי אינטגרציה עם Fireblocks: השוואת גישות

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

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

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

שלבי הטמעה: מביקורת ועד מסירת נהלים

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

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

סכמות חתימה, תפקידים ונהלים: מה אנחנו מוסרים

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

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

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

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

מה נמדד לפני

מדדו נתונים במשך חודש: שיעור האישורים הידניים — כ-70% מהפעולות, זמן חתימה ממוצע — 20-30 דקות, שחזור לאחר נפילת צומת — 4-6 שעות. גרוע מהמספרים היה סוג הכשלים: חתימה במפתח אחד בלי הסכמה שנייה, יומן בלי רישום „מי אישר”, חוסר יכולת לשלול במהירות גישה ממהנדס שעזב. חשיפת צומת אחד משמעה אובדן שליטה בכל הארנקים בבת אחת.

מה השתנה

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

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

במה שונה אחסון קוסטודיאלי מריבוי חתימות?

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

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

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

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

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

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

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

מה קורה אם צומת החתימה אינו זמין?

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

איך משחזרים גישה?

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

מי רואה את יומן פעולות המפעילים?

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

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

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

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

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