אפליקציה סלולרית סוהרת לשירותים ממשלתיים

פיתוח אפליקציית מובייל לשירותים ממשלתיים

אתה צריך אפליקציית מובייל לשירותים ממשלתיים, אבל האינטגרציה עם ESIA, Goskey ו-SMEV מורכבת, וחוקי הגנת מידע כמו 152-FZ דורשים עמידה קפדנית. אנו בונים אפליקציות מובייל לשירותים ממשלתיים במפתח מלא, ומטפלים במבוך הרגולטורי כך שתוכל להתמקד במתן ערך לאזרחים.

בעיות שאנו פותרים

הנקודה הכואבת ביותר היא אימות דרך ESIA ו-Goskey. ESIA משתמשת ב-OAuth 2.0 עם שינויים — לא סטנדרטי. חתימת בקשות היא GOST R 34.10-2012, לא RSA. ספריות סטנדרטיות כמו AppAuth עבור iOS ו-Android לא יעבדו ישירות; אתה צריך את ה-SDK של Rostelecom או ליישם חתימה בעצמך דרך CryptoPro או ViPNet.

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

val keyStore = KeyStore.getInstance("CryptoProKeyStore")
keyStore.load(null)
val privateKey = keyStore.getKey(alias, null) as PrivateKey
val signature = Signature.getInstance("GOST3411withGOST3410EL")
signature.initSign(privateKey)
signature.update(dataToSign)
val signedData = signature.sign()

ב-iOS זה מסובך יותר — אין GOST טבעי, אז אנו משתמשים ב-SDK של ViPNet CSP דרך wrapper של Obj-C/C++. Bridging Header, קישור סטטי, ניהול זיכרון ידני בנקודות קריטיות. בפרויקט אחד, זה הגדיל את val keyStore = KeyStore.getInstance("CryptoProKeyStore") keyStore.load(null) val privateKey = keyStore.getKey(alias, null) as PrivateKey val signature = Signature.getInstance("GOST3411withGOST3410EL") signature.initSign(privateKey) signature.update(dataToSign) val signedData = signature.sign() מ-1.2 ל-2.8 שניות — נאלצנו להעביר את אתחול הספק ל-thread ברקע עם בדיקת מוכנות לפני הפעולה הקריפטוגרפית הראשונה.

Goskey משולב דרך Universal Links: האפליקציה יוצרת בקשת חתימה, מעבירה אותה ל-Goskey דרך URL scheme, ומקבלת callback עם המסמך החתום. הסכמה עובדת, עם ניואנס — אם Goskey לא מותקן, יש צורך ב-fallback לגרסת web או קוד QR. טפל בזה ב-cold start / UIApplicationDelegate בזהירות: מצב המסך עשוי להשתנות בזמן שהמשתמש נמצא ב-Goskey.

אינטגרציה של Goskey שלב אחר שלב

1. הגדר Universal Link באפליקציה עבור דומיין השירותים הממשלתיים.
2. צור בקשת חתימה עם מזהה מסמך ייחודי.
3. פתח את Goskey דרך URL scheme עם פרמטרי הבקשה.
4. טפל ב-callback דרך continuation/onNewIntent ואמת את החתימה.
5. יישם fallback — גרסת web לחתימה דרך דפדפן או קוד QR.

אינטגרציה עם SMEV ו-GIS

SMEV 3 עובד דרך SOAP עם WS-Security. אפליקציית המובייל לא מתקשרת ישירות עם SMEV — רק דרך ה-backend. אבל זה לא פותר את הבעיה: סכמות XML יכולות להיות גדולות (רישומים, תעודות), ויש צורך באימות בצד הלקוח לפני שליחה. האפליקציה מטפלת בעד 10,000 בקשות בו-זמנית ל-ESIA.

עבור Android אנו משתמשים ב-Activity.onNewIntent עם XSD:

val schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI)
val schema = schemaFactory.newSchema(Source(xsdInputStream))
val validator = schema.newValidator()
validator.validate(StreamSource(xmlInputStream))

ב-iOS — javax.xml.validation דרך C bindings, או פשוט JSON API דרך proxy של backend. האפשרות השנייה פשוטה יותר אבל מאבדת שליטה מסוימת על הפורמט.

סטטוסי אפליקציה הם כאב נפרד. תהליכים ממשלתיים הם אסינכרוניים: בקשה נשלחת, מעובדת תוך 3-5 ימי עסקים, ומגיעה הודעה. אתה צריך polling או push דרך FCM/APNs. הודעות push משירותים ממשלתיים מכילות לעתים קרובות רק val schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI) val schema = schemaFactory.newSchema(Source(xsdInputStream)) val validator = schema.newValidator() validator.validate(StreamSource(xmlInputStream)) ללא פרטים — כך שבנגיעה, יש צורך בבקשה נפרדת לנתונים לפני ניווט. אם הבקשה נכשלת, הצג skeleton, אל תקרס. 95% מהמשתמשים חוזרים בגלל פרטים כאלה.

דרישות אחסון נתונים ואבטחה

152-FZ דורש אחסון נתונים אישיים בשטח רוסיה. עבור אפליקציית מובייל זה אומר: backend על שרתים רוסיים (Yandex.Cloud, SberCloud, VK Cloud), איסור העברת נתונים דרך CDNs וניתוחים זרים.

אחסון מקומי של נתונים רגישים — רק דרך libxml2 ב-Android (AES256-GCM דרך Jetpack Security) או serviceId ב-iOS עם EncryptedSharedPreferences. אסור לאחסן אסימוני הפעלה של ESIA ב-Keychain ללא הצפנה — זה מפר ישירות את דרישות הגנת הנתונים האישיים.

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

סריקת פגיעויות לפני שחרור היא חובה. אנו משתמשים ב-kSecAttrAccessibleWhenUnlocked (Mobile Security Framework) לניתוח סטטי של APK/IPA, SharedPreferences כרשימת בדיקה. תשומת לב מיוחדת ל-MobSF Activities ללא בדיקות Intent, ContentProviders לא מוגנים, ורישום אסימונים ב-LogCat.

מאפייני UX לאפליקציות ממשלתיות

בעת פיתוח אפליקציית מובייל לשירותים ממשלתיים, שקול את הקהל: אנשים בגילאי 18-80 עם רמות שונות של אוריינות דיגיטלית. גודל גופן ברירת מחדל — 16sp. תמיכה ב-Dynamic Type (iOS) ויחידות OWASP Mobile Top 10 (Android) היא חובה. מסכים עם טפסים — שלבים קצרים, ללא טפסי אשף מרובי עמודים ללא שמירת התקדמות.

נגישות (a11y): exported עבור כל אלמנט משמעותי, sp נכון ב-React Native או contentDescription ב-SwiftUI. אפליקציות ממשלתיות נבדקות מעת לעת על ידי Roskomnadzor, כולל נגישות לאנשים עם מוגבלויות.

מצב לא מקוון הוא קריטי: לא לכל המשתמשים יש אינטרנט יציב. אנו שומרים במטמון ספריות (רשימת אזורים, סוגי מסמכים) דרך Room / Core Data. סטטוסי אפליקציה מסונכרנים כשהחיבור משוחזר דרך accessibilityRole (Android) או UIAccessibilityTraits (iOS).

למה פיתוח Native עדיף על פני Cross-Platform?

פיתוח Native מהיר פי 1.5-2 בפעולות קריפטוגרפיות. עבור רוב האפליקציות הממשלתיות, פיתוח native — iOS (Swift + UIKit/SwiftUI) + Android (Kotlin + Jetpack Compose) — הוא אופטימלי. Flutter מקובל אם הצוות מוכן ואין תלות קשה בספריות קריפטוגרפיות native. React Native עם WorkManager הוא מסוכן: קריפטוגרפיית GOST דרך גשר JS אינה יציבה.

ארכיטקטורה: Clean Architecture + MVVM. שכבת Repository מבודדת את SMEV/ESIA מה-UI. UseCase מכיל לוגיקה עסקית לעיבוד סטטוסים. ViewModel מנהל את מצב המסך. הזרקת תלות — Hilt (Android) / Swinject (iOS).

בעיות ופתרונות אופייניים

מה כלול

• בחינה משפטית וטכנית של דרישות, ביקורת אינטגרציות.
• עיצוב UX בהתחשב בקהל בגילאי 18-80.
• פיתוח מודולי אימות (ESIA, Goskey), טפסים, הודעות push.
• בדיקות אינטגרציה בסביבת הבדיקה של ESIA.
• הוראות והדרכה לצוות הלקוח.
• תמיכה לאחר שחרור, ניטור שינויי API של ESIA ו-SMEV.

תהליך הערכה ועבודה

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

עיצוב: UX לקהל היעד, סכמת אימות, מודל נתונים, חוזי API עם ה-backend.

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

פרסום: RuStore הוא חובה עבור אפליקציות ממשלתיות לאחרונה. Google Play ו-App Store במקביל. הבדיקה ב-RuStore איטית יותר (5-10 ימים לעומת 1-3 ימים ב-Google Play).

תמיכה: שינויי API של ESIA וסכמות SMEV משוחררים ללא הודעה. ניטור דרך Firebase Crashlytics + התראות מותאמות אישית לשינויי מבנה תגובה.

הערכות לוחות זמנים (ללא מחירים קבועים)

MVP (אימות + 2-3 שירותים ממשלתיים): 3-5 חודשים. אפליקציה מלאה עם קטלוג שירותים רחב: 8-14 חודשים. התקציב למחזור מלא נקבע לאחר ניתוח הדרישות והיקף האינטגרציה שלך. צור קשר לייעוץ — נעריך את הפרויקט שלך ונספק הערכת לוח זמנים ועלות.

בקש ייעוץ עבור אפליקציית המובייל לשירותים ממשלתיים שלך.