פיתוח מערכת זיהוי מבוזר (DID) על בלוקצ'יין

מדוע זיהוי מבוזר DID נכשל עם הצמיחה

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

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

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

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

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

אפקט ההטמעה: זמני הנפקה, ביטול גישה, שיעור כשלים

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

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

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

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

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

אפשרויות לבניית מתאר אמון והמגבלות שלהן

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

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

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

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

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

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

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

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

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

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

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

איך זה היה לפני המעבר למתאר אחוד

רשת השותפים Альянс «Открытый контур» — 40 חברות הפועלות תחת מותג משותף. לכל אחת היה רשימת חשבונות משלה, והגישה לשירותי השכנים ניתנה לפי בקשה. חיבור עובד חדש ארך 4–6 ימי עבודה: בקשה, אישור, הזנה ידנית של חשבון בכל מערכת, מכתב עם פרטי כניסה.

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

מה שינו

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

מה השתנה לאחר ההטמעה

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

במה שונה DID מכניסה פדרטיבית?

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

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

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

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

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

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

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

כיצד מזהים מקושרים לקטלוג החשבונות הנוכחי?

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

מה עם תוקף משפטי של הרשומה?

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

נדון במשימה: מאיפה להתחיל ומה להכין

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

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

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