Wartung sicherstellen - iOS

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Wartung sicherstellen - iOS

    Wir stellen uns hier grade die Frage wie man bei einer iOS app eine optimale Wartung sicherstellen kann. Nicht aus Sicht des Kunden (wir sind immer sehr hilfsbereit :P ), eher aus unserer Sicht. Ich versuch dass mal zu erklären. Unsere App wird im wesentlichen in eher sicherheitsrelevanten Bereichen eingesetzt, wo kaum Daten wie Crashlogs an Apple verschickt werden können, auch aufgrund fehlender Internetanbindung. Trotzdem kann es ja durchaus zu Fehlern kommen, die wir natürlich supporten müssen. Wir haben deshalb ein umfangreiches Log / Trace System implementiert, welches uns als Output zugeschickt werden kann. Wie üblich werden dort Fehler/Info etc. protokolliert. Darüber hinaus sehen wir leider keine Möglichkeit weitere Funktionalität zu implementieren, die uns helfen könnte, Fehler zu analysieren. Fallen Euch noch andere Möglichkeiten ein? Bzw. wie macht Ihr das? Reichen Euch die Crashlogs? Fallen Euch weitere Lösungen ein? Einfrieren des Zustands der Anwendung zum Zeitpunkt des Fehlers?
    Danke. Kay.

  • Hängt in der Regel stark von der Definition des Begriffes "sicherheitsrelevant" ab. Am Anfang steht immer die Frage, welche Daten ein Gerät in welcher Form wohin verlassen dürfen.

    Einfrieren:
    Das Einfrieren der App hat häufig Implikationen auf den Datenschutz. Frierst Du die App mit allen zum Zeitpunkt des Crashs aktiven Daten ein? Wie schützt Du diesen Freeze gegen unbefugten Zugriff? Wie kann der Kunde entscheiden, ob diese Daten in Eure Hände gelangen dürfen (das kann ja auch eine Compliance-Vorgabe sein, z.B. Bankgeheimnis). Ist also eher kritisch.

    Logging:
    Sinnvoll, wenn möglich aber ohne Daten. Es hat sich bewährt, zumindest alle (relevanten) Methodenaufrufen, Angaben zur Netzwerkverbindung und Systeminformationen (z.B. Speicherverbrauch) zu loggen, um die für einen Crash ursächliche Methode identifizieren zu können. Dabei hast Du auch kein Problem mit Datenschutz. Diese Informationen sind (im Regelfall) auch nicht so relevant, dass Du die Logs schützen musst. Wenn Du Daten mitloggen musst, um dem Problem auf die Spur zu kommen, hast Du ggf. einen Rattenschwanz an Folgeproblemen:
    1. Musst Du die Daten für das Log random- oder pseudonymisieren?
    2. Kann die App das zum Zeitpunkt des Crashes überhaupt noch sicherstellen?
    3. Wie kannst Du diese Daten angemessen schützen (Protection Classes)?

    Grundsätzlich sollte im Sicherheitsbereich das Logging so spärlich wie möglich sein und so ausführlich wie nötig sein (-> Repudiation!)

    Übertragung:
    Anwendungsspezifisch. In "echten" Sicherheitsbereichen gehen die Daten an einen Verantwortlichen, der sie prüft und dann weitergibt. Das muss dann im SLA geregelt sein, mindestens um Euch den Rücken freizuhalten. Geht natürlich nur bei Busisness-Anwendungen für direkt adressierbare Kunden.

    Wenn Du wissen möchtest, wie man das nicht macht, guck Dir mal ein vom BSI zertifiziertes, hier nicht näher genanntes Produkt für den Aufbau von VPN-Lösungen im VS-Bereich an. Da stehen in den an den Hersteller zu schickenden, automatisch generierten Logdateien gerne IP-Adresse und sogar Passwörter drin (zumindest vor einigen Jahren war das noch so). ;)