יישמנו מודול ES עבור חברת לוגיסטיקה עם זרימת מסמכים חודשית של 20,000 מסמכים. הם איבדו 3 ימים על כל חוזה. לאחר שילוב CAdES-X Long Type 1 עם CryptoPro CSP עבור חתימות אלקטרוניות, הזמן ירד לשעתיים, וחיסכון בעלויות השליחים הסתכם ב-$1.4k–1.9k לחודש. התוקף המשפטי של החתימה מוסדר על ידי החוק הפדרלי מס' 63-FZ "על חתימות אלקטרוניות." אנו מפתחים מודולים כאלה עבור 1C-Bitrix, ומטמיעים את המחסנית הקריפטוגרפית ישירות בזרימת המסמכים שלך. עם ניסיון של למעלה מ-10 שנים — השלמנו יותר מ-30 פרויקטים. קבלו ייעוץ — נעריך לוחות זמנים והיקף באופן אישי. עלות פיתוח המודול מחושבת באופן אישי בהתאם לפורמט ומורכבות האינטגרציה.
הבטחת תוקף משפטי של החתימה
חתימות אלקטרוניות ברוסיה מוסדרות על ידי 63-FZ. לצורך תוקף משפטי, נדרשת חתימה מוסמכת (QES) עם תעודה מ-CA מוסמך. המודול שלנו משתמש ב-CryptoPro CSP, המוסמך על ידי ה-FSB של רוסיה. חתימת CAdES-X Long Type 1 כוללת חותמת זמן ותגובות OCSP, המאפשרות אימות גם לאחר 10 שנים. אנו מבטיחים שהמודול עובד כראוי עם כל CA מהרישום של משרד הפיתוח הדיגיטלי. במידת הצורך, אנו מגדירים את שרשרת האמון באמצעות תעודות שורש.
מחסנית קריפטוגרפית: CryptoPro CSP ופורמטי חתימה
התקן דה פקטו עבור ES רוסי הוא CryptoPro CSP. ביישומי אינטרנט, השילוב הבא עובד:
- CryptoPro CSP — ספק קריפטוגרפי על מחשב המשתמש (או השרת). מיישם GOST R 34.10-2012 ו-GOST R 34.11-2012
- CryptoPro Browser Plugin — יישום מקורי + תוסף עבור Chrome/Firefox/Edge
- cadesplugin.js — ספריית JavaScript לעבודה עם התוסף באמצעות
cadesplugin.CreateObjectAsync()
פורמטי חתימה שמופיעים בפועל בפרויקטים:
| פורמט | מה יש בפנים | מתי משתמשים |
|---|---|---|
| CAdES-BES | חתימה + תעודה + שרשרת | זרימת מסמכים פנימית ללא חותמת זמן |
| CAdES-T | CAdES-BES + חותמת זמן | קביעת רגע החתימה |
| CAdES-X Long Type 1 | CAdES-T + תגובות OCSP + CRL | החלפה בעלת משמעות משפטית ואחסון לטווח ארוך (עד 10 שנים) |
בפועל: CAdES-BES לתהליכים פנימיים, CAdES-X Long Type 1 למסמכים שיוצאים מהפרימטר. בחירת הפורמט משפיעה על התשתית — CAdES-X Long Type 1 דורש שרת TSP ומגיב OCSP. CAdES-X Long Type 1 מבטיח אימות חתימה פי 10 יותר מאשר CAdES-BES (עד 10 שנים לעומת 1-2 שנים ללא חתימה חוזרת). ניתן לקרוא עוד על התקן ב-ויקיפדיה.
תהליך החתימה: מלחיצה על הכפתור ועד לשרת
זהו הבלוק הטכני המרכזי. בואו נפרק אותו שכבה אחר שכבה — כל שלב מכיל מלכודות.
שלב 1: אתחול התוסף. cadesplugin.js נטען. הספרייה מזהה את הדפדפן ואת שיטת האינטראקציה. האתחול הוא אסינכרוני:
cadesplugin.then(function() { // плагин готов к работе
}, function(error) { // плагин не установлен или расширение отключено
});קריטי: אם התוסף לא מותקן, המשתמש חייב לראות הוראות עם קישורי הורדה. ב-30% מהמקרים, הבעיה היא בדיוק כאן: התוסף מותקן, אבל התוסף מושבת לאחר עדכון Chrome.
שלב 2: בחירת תעודה. ה-API של התוסף שואל את המאגר. המשתמש רואה רשימה עם שמות ותקופות תוקף. סינון לפי מטרת OID (1.3.6.1.5.5.7.3.4 — חתימת מסמכים) מצמצם את הרשימה. עבור כל תעודה, אנו בודקים:
- תקופת תוקף
- נוכחות מפתח פרטי (אם על טוקן שלא הוכנס, מחזיר
cadesplugin.then(function() { // плагин готов к работе }, function(error) { // плагин не установлен или расширение отключено });) - סטטוס ביטול ראשוני באמצעות CRL במטמון
שלב 3: יצירת חתימה. המסמך מועבר כמחרוזת Base64. תהליך עבור CAdES-BES:
- יצירת אובייקט CAdESCOM.CadesSignedData
- הגדרת התוכן
- קריאה ל-SignCades() עם התעודה וסוג החתימה
- תוצאה: מחרוזת CMS ב-Base64 (חתימה מנותקת)
כאשר קוראים ל-SignCades(), המערכת מבקשת את ה-PIN של הטוקן — זהו דיאלוג מערכת ואינו ניתן להתאמה אישית.
שלב 4: שליחה ושמירה. החתימה נשלחת לשרת באמצעות בקשת AJAX. אנו שומרים:
- מסמך מקורי
- קובץ חתימה (.sig/.p7s)
- מטא-דאטה: נושא התעודה, מספר סידורי, תאריך
עבור CAdES-X Long Type 1, התוסף עצמו יוצר קשר עם TSP ו-OCSP — אבל הם חייבים להיות נגישים. בסביבת ייצור, יש צורך ב-TSP משלך או במנוי מסחרי.
שגיאות נפוצות ופתרונות
- התוסף מותקן, התוסף מושבת — ה-promise נדחה ללא הודעה ברורה. פתרון: הוספת הוראות כיצד להפעיל את התוסף.
- התעודה קיימת, הטוקן לא מחובר — HasPrivateKey() מחזיר false. פתרון: בדיקת נוכחות הטוקן לפני החתימה.
- שרת TSP לא זמין — CAdES-X Long Type 1 נכשל. פתרון: נפילה ל-CAdES-BES עם אזהרה.
- תעודת CA לבדיקה — הכל עובד בבדיקה, אבל האימות נכשל בייצור. פתרון: הגדרת אימות שרשרת אמון.
אימות חתימה בצד השרת
האימות מתבצע באמצעות CryptoPro CSP (מותקן על השרת). עבור PHP — תוסף phpcades או קריאה ל-cryptcp דרך exec().
אנו מאמתים:
- שלמות: ה-hash של המסמך תואם ל-hash בחתימה
- תוקף התעודה: לא פגה, לא בוטלה
- שרשרת אמון: מהחותם ועד ל-CA השורשי
בדיקת ביטול — שני מסלולים:
- CRL: רשימה שמורדת מעת לעת. עד 24 שעות עיכוב
- OCSP: שאילתה בזמן אמת. OCSP מדויק פי 2 מכיוון שהוא נותן את הסטטוס הנוכחי.
התוצאה נכתבת לשדה VERIFICATION_STATUS. אימות חוזר נעשה על ידי סוכן מתוזמן.
למה אחסון חתימה לטווח ארוך חשוב
הנתונים מאוחסנים בבלוק HL או בטבלה נפרדת:
| שדה | מטרה |
|---|---|
| DOCUMENT_ID | קישור לישות (הזמנה, חוזה, חשבונית) |
| FILE_ID | מקורי ב-b_file |
| SIGNATURE_FILE_ID | קובץ חתימה |
| SIGNER_SUBJECT | נתונים מהתעודה |
| SIGN_DATE | תאריך חתימה |
| SIGN_FORMAT | CAdES-BES / CAdES-X Long Type 1 |
| VERIFICATION_STATUS | תוצאת אימות |
| VERIFICATION_DATE | תאריך אימות אחרון |
אחסון לטווח ארוך. אם מסמך מאוחסן במשך 5–10 שנים, אלגוריתמי GOST עשויים להתיישן, והתעודה עלולה לפג. פתרון: חתימה חוזרת תקופתית — הוספת חותמת זמן חדשה. סוכן רץ פעם בחודש כדי לבדוק אם חותמת הזמן עומדת לפג בתוך 6 החודשים הקרובים ומוסיף חדשה. ללא זה, לאחר 3–5 שנים, חתימת CAdES-X Long Type 1 הופכת לבלתי ניתנת לאימות.
מה כלול בעבודה
- ניתוח דרישות ותשתית (זמינות CryptoPro, סוגי תעודות, פורמטי חתימה)
- פיתוח מודול: צד לקוח (cadesplugin) + צד שרת (ולידציה, אחסון)
- אינטגרציה עם ישויות Bitrix נדרשות (הזמנות, חשבוניות, חוזים)
- הגדרת בדיקות CRL/OCSP וסוכן החתימה החוזרת
- תיעוד API והוראות משתמש
- הכשרת מנהלים ומפעילים
- 6 חודשי תמיכה טכנית לאחר ההשקה
מודול זה הוא רכיב תשתיתי. המורכבות שלו אינה בנפח הקוד אלא במספר התלויות החיצוניות: ספק קריפטוגרפי, תוסף, TSP, OCSP, תעודות שורש. כל אלמנט דורש הגדרה וניטור. לוחות זמנים לפיתוח — משבועיים עד חודשיים, בהתאם לפורמט ומספר האינטגרציות. העלות מחושבת באופן אישי לאחר ניתוח. הזמינו ייעוץ — נשלח הצעה מסחרית עם מחיר מדויק ולוח זמנים.