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

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

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

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

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

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

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

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

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

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

מצבי חתימה: מה בוחרים ולמה

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

אחסון מפתחות ומודול קריפטוגרפי חומרתי

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

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

מה מספק אפקט מדיד

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה השתנה במדדים

• שיעור המסמכים שנחתמו בניסיון הראשון עלה מ-60% ל-97% — חתימות חוזרות נעלמו כמעט לחלוטין.
• הזמן מרגע הלחיצה על "לחתום" ועד לקובץ המוגמר במערכת הצטמצם מכמה שעות (המתנה לחזרה למשרד) ל-2-4 דקות לאחר הופעת הקישוריות.
• הפניות לתמיכה בגין ניתוקי חתימה ירדו ביותר מפי חמישה — העומס על קו ראשון פחת, ומהנדסים הפסיקו להתקשר מהאתר.

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

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

תאימות, חזרה לאחור והרשאות: מה יש לדון לפני ההתחלה

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

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

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

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

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

מה הלקוח מקבל לידיו:

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

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

לוחות זמנים של שלבי הטמעת חתימה ניידת

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

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

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

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

תארו את תרחישי החתימה שלכם — נחזור עם הערכה ותוכנית לפי שלבים.