ביקורת פעילות משתמשים ביישומים ניידים ארגוניים

ביקורת פעילות משתמשים ביישומים ניידים ארגוניים

אנו מפתחים ומיישמים מסלולי ביקורת (Audit Trail) ביישומים ניידים ארגוניים כדי להבטיח עמידה ברגולציות במגזרים הפיננסיים, הרפואיים והממשלתיים. מסלול ביקורת אבטחה אינו אנליטיקה או מחקר UX. מדובר ביומנים בעלי משמעות משפטית שמראים, בזמן אירוע: מי, מתי, ומאיזה מכשיר פתח מסמך, שינה רשומה או ייצא קובץ. ללא זה, חקירת דליפה היא בלתי אפשרית. הניסיון שלנו מראה ש-80% מהחברות נתקלות בבעיות בעת ניתוח אירועים עקב חוסר ביומנים מובנים. אנו מציעים פתרון מקצה לקצה: החל מביקורת על רישום קיים ועד להטמעת מסלול ביקורת מוגן עם חתימות HMAC ושילוב SIEM. אנו מעריכים את הפרויקט שלכם ומספקים המלצות. עם ניסיון של למעלה מ-7 שנים באבטחה ניידת ויותר מ-150 פרויקטים שהושלמו, אנו מבטיחים שמסלול הביקורת שלכם עומד בתקני ISO 27001 וברגולציות התעשייה.

מה חייב להיות מתועד?

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

• התחברות והתנתקות (כולל התנתקות אוטומטית בזמן קצוב)
• גישה למסמכים או רשומות עם סיווג גבוה מ'פנימי'
• שינוי, יצירה, מחיקה של נתונים
• ייצוא, הדפסה, שליחה — כל הוצאת נתונים מחוץ לתחום היישום
• ניסיונות אימות כושלים (עם מונה)
• שינויים בהגדרות אבטחה (PIN, ביומטריה)
• פקודות מחיקה מרחוק וביצוען

רישום 'המשתמש לחץ על כפתור חזור' אינו ביקורת; זה רעש.

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

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

לאספקה אמינה — תור מקומי עם שליחה מובטחת. באנדרואיד — WorkManager עם BackoffPolicy.EXPONENTIAL, ב-iOS — BGProcessingTask. היומנים נכתבים תחילה לטבלת SQLite מקומית, ולאחר מכן משימה ברקע שולחת אותם לשרת ומוחקת אותם רק לאחר אישור. גישה זו אמינה פי 3 משליחה סינכרונית, שמאבדת עד 15% מהאירועים בזמן רשת לא יציבה.

// Модель события аудита
data class AuditEvent(
    val id: String = UUID.randomUUID().toString(),
    val timestamp: Long = System.currentTimeMillis(),
    val userId: String,
    val deviceId: String,
    val action: AuditAction,
    val resourceId: String?,
    val resourceType: String?,
    val metadata: Map<String, String> = emptyMap(),
    val synced: Boolean = false
)

enum class AuditAction {
    LOGIN, LOGOUT, DOCUMENT_VIEW, DOCUMENT_EXPORT, RECORD_CREATE, RECORD_UPDATE, RECORD_DELETE, AUTH_FAILURE, SETTINGS_CHANGE, WIPE_RECEIVED
}

// DAO для локальной очереди
@Dao
interface AuditEventDao {
    @Insert
    suspend fun insert(event: AuditEvent)

    @Query("SELECT * FROM audit_events WHERE synced = 0 ORDER BY timestamp ASC LIMIT 50")
    suspend fun getUnsynced(): List<AuditEvent>

    @Query("UPDATE audit_events SET synced = 1 WHERE id IN (:ids)")
    suspend fun markSynced(ids: List<String>)
}

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

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

אם היישום פועל על מכשיר עם root/jailbreak, המשתמש יכול למחוק את ה-SQLite המקומי. לדרישות אבטחה גבוהות, כל אירוע נחתם עם מפתח HMAC מ-Android Keystore / iOS Secure Enclave:

fun signEvent(event: AuditEvent): String {
    val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }
    val privateKey = keyStore.getKey("audit_signing_key", null)
    val signature = Signature.getInstance("SHA256withECDSA")
    signature.initSign(privateKey as PrivateKey)
    signature.update(event.toCanonicalBytes())
    return Base64.encodeToString(signature.sign(), Base64.NO_WRAP)
}

השרת מאמת את החתימה באמצעות המפתח הציבורי. זיוף יומן ללא גישה ל-Secure Enclave הוא בלתי אפשרי.

העשרת הקשר

// Модель события аудита data class AuditEvent( val id: String = UUID.randomUUID().toString(), val timestamp: Long = System.currentTimeMillis(), val userId: String, val deviceId: String, val action: AuditAction, val resourceId: String?, val resourceType: String?, val metadata: Map<String, String> = emptyMap(), val synced: Boolean = false ) enum class AuditAction { LOGIN, LOGOUT, DOCUMENT_VIEW, DOCUMENT_EXPORT, RECORD_CREATE, RECORD_UPDATE, RECORD_DELETE, AUTH_FAILURE, SETTINGS_CHANGE, WIPE_RECEIVED } חשוף הוא המינימום. תוספות שימושיות:

• // DAO для локальной очереди @Dao interface AuditEventDao { @Insert suspend fun insert(event: AuditEvent) @Query("SELECT * FROM audit_events WHERE synced = 0 ORDER BY timestamp ASC LIMIT 50") suspend fun getUnsynced(): List<AuditEvent> @Query("UPDATE audit_events SET synced = 1 WHERE id IN (:ids)") suspend fun markSynced(ids: List<String>) } — מקשר למכשיר ספציפי, לא לחשבון
• fun signEvent(event: AuditEvent): String { val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) } val privateKey = keyStore.getKey("audit_signing_key", null) val signature = Signature.getInstance("SHA256withECDSA") signature.initSign(privateKey as PrivateKey) signature.update(event.toCanonicalBytes()) return Base64.encodeToString(signature.sign(), Base64.NO_WRAP) } — כדי להבין באיזו גרסה התרחש האירוע
• userId + action + timestamp (WiFi/LTE/VPN) — מראה האם ה-VPN הארגוני היה פעיל
• deviceId — דגלים מ-SafetyNet / DeviceCheck

באנדרואיד, appVersion הוא networkType (ייחודי לכל שילוב של מכשיר+משתמש+יישום מאז אנדרואיד 8). ב-iOS, זה jailbreak/root detected.

אחסון בשרת

יומני ביקורת אינם נמחקים לאחר 30 יום. דרישות חוקיות (תלוי בתעשייה): משנה אחת (סטנדרטי) עד 7 שנים (ארגונים פיננסיים לפי חוק פדרלי 115). אחסון במסד נתונים append-only — PostgreSQL עם טבלאות deviceId-בלבד ואיסור Settings.Secure.ANDROID_ID באמצעות Row Level Security, או SIEM נפרד (Splunk, ELK עם ILM). ISO 27001 ממליץ לאחסן יומנים לפחות שנה אחת.

לאחסון, PostgreSQL עם RLS הוא פשוט יותר ומספיק לעד 10 מיליון רשומות; מעבר לכך, SIEM מספק חיפוש מהיר יותר וסיבוב אוטומטי, אך בעלות גבוהה פי 2–3. אנו ממליצים על PostgreSQL לרוב הארגונים הבינוניים ועל SIEM לבנקים גדולים או מערכות בריאות.

מה כוללת העבודה שלנו?

אנו מספקים מגוון מלא של שירותים להטמעת מסלול ביקורת:

לוח זמנים: 2 עד 6 ימים תלוי במורכבות. עלות פרויקט טיפוסית מתחילה ב-$5,000, עם חיסכון של 30% בהכנת ביקורת פנימית ותגובה לאירוע מהירה ב-50%. אנו מציעים ייעוץ ראשוני להערכת הצרכים שלכם. צרו קשר לדיון בפרטים.

מה לבדוק במהלך ביקורת יישום?

לעתים קרובות אנו מוצאים שהיישום כבר כולל 'רישום כלשהו' — אבל הוא כותב ל-Logcat או לקובץ ב-UIDevice.current.identifierForVendor, שמתנקה כשהשטח נגמר. זה לא מסלול ביקורת; זה זבל. הצוות שלנו מבצע ביקורת ומראה כיצד לתקן את המצב.

תהליך ההטמעה כולל את השלבים הבאים:

1. ניתוח דרישות וביקורת רישום נוכחי.
2. עיצוב סכמת אירועים ומטא-דאטה.
3. הטמעת תור מקומי עם אספקה מובטחת.
4. חתימת HMAC לשלמות.
5. שילוב אחסון בשרת (PostgreSQL או SIEM).
6. בדיקות והדרכת צוות.

הערה: עמידה בהנחיות סקירת ה-App Store (סעיפים 4.2 ו-5.1) מובטחת באמצעות רישום נכון וטיפול בפרטיות.